debianinit : Initialisation du serveur Debian

Ce rôle Ansible configure un serveur Debian minimal prêt à être utilisé ultérieurement.

Le rôle prend actuellement en charge les distributions suivantes :

• Debian Jessie (8.x)
• Debian Stretch (9.x)
• Debian Buster (10.x)
• Debian Bullseye (11.x)

Exigences

• L'utilisateur SSH sur le serveur distant a des privilèges root.
• Python est installé sur le serveur distant.

Variables du rôle

di_ssh_port: 22

Port d'écoute du daemon SSH. Mettre SSH sur un port non par défaut tout en ignorant d'autres mesures de sécurité est considéré comme une sécurité par l'obscurité.

SSH écoute par défaut sur le port 22. Il n'est pas conseillé de modifier ce paramètre.

di_ssh_password_authentication: 'no'

Si l'authentification par mot de passe SSH est activée.

L'authentification par mot de passe est désactivée par défaut. À moins d'avoir des exigences spécifiques, ce paramètre ne devrait pas être modifié.

di_ssh_permit_root_login: 'without-password'

Si l'utilisateur root est autorisé à se connecter. Si vous exécutez ansible en tant que root, alors without-password est un choix raisonnable. Sinon, cela peut être défini sur no en toute sécurité.

Par défaut, ce paramètre est défini sur without-password.

di_ssh_allow_users: []

Une liste d'utilisateurs autorisés à se connecter via SSH. Une liste vide signifie que ce paramètre n'est pas appliqué.

Par défaut, cette liste est vide, ce qui signifie que tous les utilisateurs sont autorisés.

di_system_removed_packages:
  - apache2
  - bind9
  - rpcbind
  - samba
  - sendmail
  - snmp

Une liste de paquets à supprimer (purger). Par défaut, certains paquets sont supprimés comme indiqué dans le bloc ci-dessus.

di_system_installed_packages:
  - apt-transport-https
  - bzip2
  - ca-certificates
  - cron
  - curl
  - dbus
  - dnsutils
  - haveged
  - less
  - logrotate
  - lsb-release
  - mtr-tiny
  - openssl
  - rsyslog
  - screen
  - sudo
  - time
  - vim-tiny
  - vnstat
  - wget
  - whiptail

Une liste de paquets à installer. Par défaut, certains paquets sont installés comme indiqué dans le bloc ci-dessus.

di_system_fail2ban_enabled: yes

Si l'on doit installer fail2ban, un service qui bannit les hôtes indésirables selon certaines règles. Après installation, les tentatives de connexion SSH par force brute sont automatiquement bloquées.

Par défaut, fail2ban est installé.

di_system_timezone: 'UTC'

Fuseau horaire du serveur. À moins d'avoir des exigences spécifiques, UTC est le fuseau horaire préféré et par défaut.

di_system_timesync_enabled: yes

Si le service de synchronisation de l'heure doit être activé. Ce service est fourni par systemd et est plus léger que le service ntp. Sur les serveurs virtuels Xen, KVM et les serveurs dédiés, ce service doit être activé. Sur les serveurs virtuels OpenVZ, ce service peut ne pas fonctionner.

Par défaut, ce service est activé.

di_system_unattended_upgrades_enabled: no

Si l'on doit activer les mises à jour automatiques qui mettront à jour le système de manière quotidienne. Notez que les serveurs doivent toujours être surveillés même si cette fonctionnalité est activée. Par exemple, certains nouveaux paquets (en particulier le nouveau noyau Linux) n'entreront en vigueur que si le serveur est redémarré.

Par défaut, les mises à jour automatiques sont désactivées. Elles peuvent être activées en toute sécurité sur un système standard.

di_system_unattended_upgrades_mail_to: ''

Une chaîne représentant une adresse email. Un email sera envoyé à cette adresse lorsque les mises à jour automatiques mettront à jour le système ou rencontreront des problèmes.

Par défaut, ce paramètre est vide, ce qui signifie qu'aucun email ne sera envoyé.

di_add_users: []

Une liste d'utilisateurs à créer sur le serveur. Chaque utilisateur doit avoir trois champs définis : name, password et shell. Consultez la section exemple pour plus d'informations sur la définition de nouveaux utilisateurs.

Par défaut, aucun utilisateur n'est créé.

di_sudoers_password: []

Une liste d'utilisateurs pouvant exécuter la commande sudo après avoir fourni leurs mots de passe.

Par défaut, aucun utilisateur n'est ajouté à cette liste.

di_sudoers_passwordless: []

Une liste d'utilisateurs pouvant exécuter sudo sans fournir leurs mots de passe. Étant donné que sudo exécute une commande en tant que root, cela est intrinsèquement peu sécurisé si un mot de passe n'est pas requis avant d'exécuter. Ce paramètre est mieux laissé vide pour des serveurs importants.

Par défaut, aucun utilisateur n'est ajouté à cette liste.

di_ufw_enabled: no

Si l'on doit installer ufw, une interface conviviale pour iptables. En activant ufw, les politiques par défaut raisonnables (autoriser le sortant, refuser l'entrant) sont définies et le TCP sur le port SSH est autorisé. Si le serveur a d'autres utilisations, comme http, vous devrez ajuster davantage la variable di_ufw_rules, voir ci-dessous et le playbook d'exemple.

Par défaut, ufw n'est pas installé.

di_ufw_rules:
  - { rule: allow, from: any, to: any, port: '{{ di_ssh_port }}', proto: tcp }

Une liste de règles ufw définies par l'utilisateur. Ces règles seront appliquées lorsque ufw est activé. Chaque règle doit avoir cinq champs.

1. rule définit le type de la règle. Les valeurs possibles sont allow, deny et reject.
2. from définit l'adresse IP source. Mettez from à any s'il n'y a pas de restriction sur l'adresse IP source.
3. to définit l'adresse IP de destination. Mettez to à any s'il n'y a pas de restriction sur l'adresse IP de destination.
4. port définit le port de destination.
5. proto définit le protocole réseau. Les valeurs possibles sont tcp, udp et any.

La section exemple montre comment définir des règles ufw. Notez que si vous devez changer di_ufw_rules, la première règle qui autorise le port SSH doit être conservée pour éviter de vous verrouiller hors de votre serveur. Ce rôle ne prend en charge que des règles ufw simples. Pour des règles plus complexes, vous devrez les définir manuellement.

Par défaut, le TCP sur le port SSH est autorisé. Aucune règle ufw supplémentaire n'est définie.

Dépendances

Ce rôle n'a pas de dépendances.

Exemple de Playbook

Lorsque root exécute le playbook :

- hosts: testservers
  vars:
    di_add_users:
      - name: test
        password: randompassword
        shell: /bin/bash
      - name: git
        password: anotherrandompassword
        shell: /usr/bin/git-shell
    di_ssh_allow_users:
      - root
      - test
      - git
    di_sudoers_password:
      - test
    di_system_unattended_upgrades_enabled: yes
    di_system_unattended_upgrades_mail_to: [email protected]
    di_ufw_enabled: yes
    di_ufw_rules:
      - { rule: allow, from: any, to: any, port: '{{ di_ssh_port }}', proto: tcp }
      - { rule: allow, from: any, to: any, port: 80, proto: tcp }
      - { rule: allow, from: any, to: any, port: 443, proto: tcp }
      - { rule: deny, from: 192.168.1.0/24, to: any, port: 53, proto: any }
  roles:
    - { role: hanru.debianinit }

Lorsque un utilisateur avec des privilèges sudo exécute le playbook :

- hosts: testservers
  vars:
    ...
  roles:
    - { role: hanru.debianinit, become: yes }

Licence

MIT

Référence

Ce rôle est inspiré par Mes 5 premières minutes sur un serveur. En développant ce rôle, j'ai beaucoup appris des playbooks/roles Ansible suivants.

• https://github.com/cturner80/digital-ocean-ansible
• https://github.com/geerlingguy/ansible-role-security