githubixx.harden_linux

ansible-role-harden-linux

Ce rôle Ansible a été principalement créé pour ma série d'articles de blog Kubernetes the not so hard way with Ansible - Harden the instances. Mais il peut bien sûr être utilisé seul pour sécuriser Linux. Il possède les fonctionnalités suivantes (certaines sont optionnelles) :

Ajouter un utilisateur régulier/déploiement utilisé pour l'administration (par exemple pour Ansible ou se connecter via SSH)
Ajuster les intervalles de mise à jour APT
Configurer le pare-feu UFW et autoriser uniquement l'accès SSH par défaut (ajoutez plus de règles/réseaux autorisés si vous le souhaitez)
Ajuster les paramètres sysctl liés à la sécurité
Modifier les paramètres sshd, par exemple désactiver l'authentification par mot de passe, désactiver la connexion root par SSH et désactiver PermitTunnel
Installer/configurer sshguard et ajuster la liste blanche
Changer le mot de passe root
Installer/configurer la synchronisation de l'heure réseau (NTP) par exemple openntpd/ntp/systemd-timesyncd
Modifier la configuration de systemd-resolved

Versions

Je tague chaque version et j'essaie de suivre la gestion sémantique des versions. Si vous voulez utiliser le rôle, je vous recommande de vérifier le dernier tag. La branche master est essentiellement pour le développement, tandis que les tags marquent les versions stables. En général, j'essaie aussi de garder master en bon état.

Journal des modifications

Historique des modifications :

Voir le CHANGELOG.md

Changements récents :

v8.2.0

FONCTIONNALITÉ
- Ajout du support pour Ubuntu 24.04

v8.1.0

AUTRE
- Mise à jour des commentaires concernant l'utilisation de mkpasswd au lieu d'ansible pour créer un mot de passe crypté
- Ubuntu : ajout d'une tâche d'auto suppression
- Mise à jour du workflow Github
MOLECULE
- Utilisation de alvistack au lieu de boîtes Vagrant génériques
- Utilisation d'adresses IP différentes

v8.0.0

CAS DE CAS DE RUPTURE/FONCTIONNALITÉ
- Introduction des variables harden_linux_deploy_group et harden_linux_deploy_group_gid. Les deux sont optionnelles. Mais au moins harden_linux_deploy_group doit être spécifié si harden_linux_deploy_user est également défini. Si harden_linux_deploy_group est défini sur root, rien ne sera modifié.
- Si harden_linux_deploy_user est défini sur root, rien ne sera modifié.
- harden_linux_deploy_user est désormais optionnel. S'il n'est pas défini, aucun utilisateur ne sera configuré. Toutes les variables commençant par harden_linux_deploy_user_ ne sont utilisées que si harden_linux_deploy_user est spécifié. De plus, la variable harden_linux_deploy_user_home a été ajoutée. harden_linux_deploy_user_shell, harden_linux_deploy_user_home, harden_linux_deploy_user_uid et harden_linux_deploy_user_password sont désormais optionnels. Le répertoire $HOME de harden_linux_deploy_user n'est créé que si harden_linux_deploy_user_home est défini.
MOLECULE
- Mise à jour du scénario de test pour refléter les modifications de l'utilisateur/groupe de déploiement

Installation

Téléchargez directement depuis Github (changez dans le répertoire du rôle Ansible avant de cloner. Vous pouvez trouver le chemin du rôle en utilisant la commande ansible-config dump | grep DEFAULT_ROLES_PATH) : git clone https://github.com/githubixx/ansible-role-harden-linux.git githubixx.harden_linux
Via la commande ansible-galaxy et téléchargez directement depuis Ansible Galaxy : ansible-galaxy install role githubixx.harden_linux
Créez un fichier requirements.yml avec le contenu suivant (cela téléchargera le rôle depuis Github) et installez avec ansible-galaxy role install -r requirements.yml (modifiez version si nécessaire) :

---
roles:
  - name: githubixx.harden_linux
    src: https://github.com/githubixx/ansible-role-harden-linux.git
    version: v8.1.0

Variables du Rôle

Les variables suivantes n'ont pas de valeurs par défaut. Vous devez les spécifier soit dans un fichier dans le répertoire group_vars ou host_vars. Par exemple, si ces paramètres doivent être utilisés uniquement pour un hôte spécifique, créez un fichier pour cet hôte avec le nom du FQDN de cet hôte (e.g. host_vars/your-server.example.tld) et mettez les variables avec les valeurs correctes. Si vous souhaitez appliquer ces variables à un groupe d'hôtes, créez un fichier group_vars/your-group.yml par exemple, Remplacez your-group par le nom du groupe d'hôtes que vous avez créé dans le fichier hosts d'Ansible (ne pas confondre avec /etc/hosts...).

Si vous souhaitez définir ou modifier le mot de passe de l'utilisateur root, définissez la variable harden_linux_root_password. C'est optionnel. Cela s'attend à un mot de passe crypté. Ansible ne cryptera pas le mot de passe pour vous. Comment créer un mot de passe crypté est décrit dans les FAQ d'Ansible. Sur Linux, la commande suivante est probablement la plus fiable :

mkpasswd --method=sha-512

Pour installer un utilisateur qui peut exécuter des commandes avec sudo sans mot de passe, définissez les variables suivantes :

harden_linux_deploy_user: "a_username"
harden_linux_deploy_user_password: "a_password"
harden_linux_deploy_user_home: "/home/a_user"
harden_linux_deploy_user_uid: "9999"
harden_linux_deploy_user_gid: "9999"
harden_linux_deploy_user_shell: "/bin/bash"

harden_linux_deploy_user spécifie l'utilisateur que nous voulons utiliser pour se connecter à l'hôte distant. Comme déjà mentionné, le rôle harden_linux désactive la connexion root par SSH pour une bonne raison. Donc, un utilisateur différent est nécessaire. Cet utilisateur obtiendra les autorisations "sudo" qui sont nécessaires pour qu'Ansible (et/ou vous-même, bien sûr) puisse effectuer son travail.

Dans harden_linux_deploy_user_password, le mot de passe crypté de l'utilisateur est stocké. Même chose que pour harden_linux_root_password concernant la création d'un mot de passe crypté.

Le répertoire $HOME de l'utilisateur est spécifié dans harden_linux_root_password. Pour l'UID et GID, définissez harden_linux_deploy_user_uid et harden_linux_deploy_user_gid. Remarque : Si l'utilisateur existe déjà mais a un répertoire personnel, un UID et/ou GID différents, cela sera modifié selon les paramètres ci-dessus ! Cela s'applique également à harden_linux_deploy_user_shell, qui spécifie le shell que l'utilisateur doit utiliser après la connexion par exemple.

harden_linux_deploy_user_public_keys spécifie une liste des fichiers de clés SSH publiques que vous souhaitez ajouter à $HOME/.ssh/authorized_keys de l'utilisateur de déploiement sur l'hôte distant. Si vous spécifiez /home/deploy/.ssh/id_rsa.pub par exemple, le contenu de ce fichier local (présent sur le nœud de contrôle Ansible) sera ajouté à $HOME/.ssh/authorized_keys de l'utilisateur de déploiement sur l'hôte distant.

harden_linux_optional_packages (avant la version v6.0.0 de ce rôle, cette variable s'appelait harden_linux_required_packages) spécifie des paquets supplémentaires/optionnels à installer sur l'hôte distant. Par défaut, cette variable n'est pas spécifiée. Par exemple :

harden_linux_optional_packages:
  - vim

Contrairement à l'ancienne variable, harden_linux_absent_packages désinstallera des paquets OS sur l'hôte distant. Par défaut, cette variable n'est pas spécifiée. Par exemple :

harden_linux_absent_packages:
  - vim

Les variables suivantes ont des valeurs par défaut. Vous devez donc les modifier uniquement si vous avez besoin d'une autre valeur pour la variable. Le rôle modifie par défaut certains paramètres sshd :

harden_linux_sshd_settings:
  "^PasswordAuthentication": "PasswordAuthentication no"  # Désactiver l'authentification par mot de passe
  "^PermitRootLogin": "PermitRootLogin no"                # Désactiver la connexion SSH root
  "^PermitTunnel": "PermitTunnel no"                      # Désactiver le transfert de périphérique tun(4)
  "^Port ": "Port 22"                                     # Définir le port sshd

Personnellement, je change toujours le port SSH par défaut car beaucoup d'attaques par force brute ont lieu contre ce port (mais bien sûr, un analyseur de port sera tout de même capable de le découvrir rapidement). Donc si vous souhaitez changer le paramètre de port, vous pouvez le faire par exemple :

harden_linux_sshd_settings_user:
  "^Port ": "Port 22222"

(Veuillez noter l'espace après ^Port !). Le playbook combinera harden_linux_sshd_settings et harden_linux_sshd_settings_user, tandis que les paramètres dans harden_linux_sshd_settings_user ont la préférence, ce qui signifie qu'ils remplaceront le paramètre/clé ^Port dans harden_linux_sshd_settings. Comme vous l'avez peut-être remarqué, toutes les clés dans harden_linux_sshd_settings et harden_linux_sshd_settings_user commencent par ^. C'est parce que c'est une expression régulière (regex). Une des tâches du playbook recherchera une ligne dans /etc/ssh/sshd_config, par exemple ^Port (tandis que le ^ signifie "une ligne commençant par ...") et remplacera la ligne (si trouvée) par exemple Port 22222. De cette manière, le playbook est très flexible pour ajuster les paramètres dans sshd_config (vous pouvez essentiellement remplacer n'importe quel paramètre). Vous verrez ce schéma pour d'autres tâches également. Donc tout ce qui est mentionné ici est vrai dans de tels cas.

Ensuite, quelques paramètres par défaut pour le pare-feu/iptables. Les règles et paramètres du pare-feu/iptables sont gérés par UFW :

harden_linux_ufw_defaults:
  "^IPV6": 'IPV6=yes'
  "^DEFAULT_INPUT_POLICY": 'DEFAULT_INPUT_POLICY="DROP"'
  "^DEFAULT_OUTPUT_POLICY": 'DEFAULT_OUTPUT_POLICY="ACCEPT"'
  "^DEFAULT_FORWARD_POLICY": 'DEFAULT_FORWARD_POLICY="DROP"'
  "^DEFAULT_APPLICATION_POLICY": 'DEFAULT_APPLICATION_POLICY="SKIP"'
  "^MANAGE_BUILTINS": 'MANAGE_BUILTINS=no'
  "^IPT_SYSCTL": 'IPT_SYSCTL=/etc/ufw/sysctl.conf'
  "^IPT_MODULES": 'IPT_MODULES="nf_conntrack_ftp nf_nat_ftp nf_conntrack_netbios_ns"'

Ces paramètres changent essentiellement les valeurs dans /etc/defaults/ufw. Pour remplacer une ou plusieurs des valeurs par défaut, vous pouvez le faire en spécifiant la même clé (qui est une regex) que ci-dessus, par exemple ^DEFAULT_FORWARD_POLICY et en lui attribuant simplement la nouvelle valeur :

harden_linux_ufw_defaults_user:
  "^DEFAULT_FORWARD_POLICY": 'DEFAULT_FORWARD_POLICY="ACCEPT"'

Comme déjà mentionné ci-dessus, ce playbook combinera également harden_linux_ufw_defaults et harden_linux_ufw_defaults_user, tandis que les paramètres dans harden_linux_ufw_defaults_user ont la préférence.

Ensuite, nous pouvons spécifier certaines règles de pare-feu avec harden_linux_ufw_rules. Par défaut, cela permet le trafic SSH sur le port 22, utilisant le protocole tcp :

harden_linux_ufw_rules:
  - rule: "allow"
    to_port: "22"
    protocol: "tcp"

Les paramètres disponibles avec des valeurs par défaut (le cas échéant) :

rule (pas de valeur par défaut)
interface (valeur par défaut '')
direction (valeur par défaut 'in')
from_ip (valeur par défaut 'any')
to_ip (valeur par défaut 'any')
from_port (valeur par défaut '')
to_port (valeur par défaut '')
protocol (valeur par défaut 'any')
log (valeur par défaut 'false')
delete (valeur par défaut 'false')

Une règle peut avoir les valeurs allow, deny, limit et reject. L'interface spécifie l'interface pour la règle. La direction (in ou out) utilisée pour l'interface. L'adresse IP source spécifie l'adresse IP source et l'adresse IP de destination spécifie l'adresse IP de destination. Le protocole est any par défaut. Les valeurs possibles sont tcp, udp, ipv6, esp, ah, gre et igmp. Le log peut être soit false (par défaut) ou true et spécifie si les nouvelles connexions correspondant à cette règle doivent être enregistrées. Le delete spécifie si une règle doit être supprimée. Cela est important si une règle précédemment ajoutée doit être supprimée. Il ne suffit pas de retirer une règle de harden_linux_ufw_rules ! Vous devez utiliser delete pour supprimer cette règle.

Vous pouvez également autoriser les hôtes à communiquer sur des réseaux spécifiques (sans restrictions de port) par exemple :

harden_linux_ufw_allow_networks:
  - "10.3.0.0/24"
  - "10.200.0.0/16"

Ensuite, le rôle harden_linux modifie également certaines variables système (sysctl.conf / système de fichiers proc). Ces paramètres sont des recommandations de Google qu'ils utilisent pour leurs images OS de Google Compute Cloud (voir Google Cloud - Exigences pour construire des images personnalisées et Configurer votre image importée pour Compute Engine). Voici les paramètres par défaut (si vous êtes satisfait de ces paramètres, vous n'avez rien à faire mais je recommande de vérifier s'ils fonctionnent pour votre configuration) :

harden_linux_sysctl_settings:
  "net.ipv4.tcp_syncookies": 1                    # Activer la protection contre les attaques par syn flood
  "net.ipv4.conf.all.accept_source_route": 0      # Ignorer les paquets source-routés
  "net.ipv6.conf.all.accept_source_route": 0      # IPv6 - Ignorer les redirections ICMP
  "net.ipv4.conf.default.accept_source_route": 0  # Ignorer les paquets source-routés
  "net.ipv6.conf.default.accept_source_route": 0  # IPv6 - Ignorer les paquets source-routés
  "net.ipv4.conf.all.accept_redirects": 0         # Ignorer les redirections ICMP
  "net.ipv6.conf.all.accept_redirects": 0         # IPv6 - Ignorer les redirections ICMP
  "net.ipv4.conf.default.accept_redirects": 0     # Ignorer les redirections ICMP
  "net.ipv6.conf.default.accept_redirects": 0     # IPv6 - Ignorer les redirections ICMP
  "net.ipv4.conf.all.secure_redirects": 1         # Ignorer les redirections ICMP des hôtes non-GW
  "net.ipv4.conf.default.secure_redirects": 1     # Ignorer les redirections ICMP des hôtes non-GW
  "net.ipv4.ip_forward": 0                        # Ne pas autoriser le trafic entre les réseaux ou agir en tant que routeur
  "net.ipv6.conf.all.forwarding": 0               # IPv6 - Ne pas autoriser le trafic entre les réseaux ou agir en tant que routeur
  "net.ipv4.conf.all.send_redirects": 0           # Ne pas autoriser le trafic entre les réseaux ou agir en tant que routeur
  "net.ipv4.conf.default.send_redirects": 0       # Ne pas autoriser le trafic entre les réseaux ou agir en tant que routeur
  "net.ipv4.conf.all.rp_filter": 1                # Filtrage de chemin inverse - Protection contre le spoofing IP
  "net.ipv4.conf.default.rp_filter": 1            # Filtrage de chemin inverse - Protection contre le spoofing IP
  "net.ipv4.icmp_echo_ignore_broadcasts": 1       # Ignorer les diffusions ICMP pour éviter de participer à des attaques Smurf
  "net.ipv4.icmp_ignore_bogus_error_responses": 1 # Ignorer les mauvaises erreurs ICMP
  "net.ipv4.icmp_echo_ignore_all": 0              # Ignorer les mauvaises erreurs ICMP
  "net.ipv4.conf.all.log_martians": 1             # Journaliser les paquets spoofés, source-routés et redirigés
  "net.ipv4.conf.default.log_martians": 1         # Journaliser les paquets spoofés, source-routés et redirigés
  "net.ipv4.tcp_rfc1337": 1                       # Implémenter le correctif RFC 1337
  "kernel.randomize_va_space": 2                  # Randomiser les adresses de la base mmap, heap, stack et page VDSO
  "fs.protected_hardlinks": 1                     # Fournir une protection contre les courses ToCToU
  "fs.protected_symlinks": 1                      # Fournir une protection contre les courses ToCToU
  "kernel.kptr_restrict": 1                       # Rendre la localisation des adresses noyau plus difficile
  "kernel.perf_event_paranoid": 2                 # Rendre perf disponible uniquement au root

Vous pouvez remplacer chaque paramètre en créant par exemple une variable appelée harden_linux_sysctl_settings_user :

harden_linux_sysctl_settings_user:
  "net.ipv4.ip_forward": 1
  "net.ipv6.conf.default.forwarding": 1
  "net.ipv6.conf.all.forwarding": 1

Une des tâches du playbook combinera harden_linux_sysctl_settings et harden_linux_sysctl_settings_user, tandis que les paramètres de harden_linux_sysctl_settings_user auront la préférence. Consultez le fichier defaults/main.yml du rôle pour plus d'informations sur les paramètres.

Si vous souhaitez activer la journalisation UFW, définissez :

harden_linux_ufw_logging: 'on'

Les valeurs possibles sont on, off, low, medium, high et full.

Ensuite, nous avons les paramètres "sshguard". "sshguard" protège contre les attaques par force brute contre SSH. Pour éviter de vous verrouiller pendant un certain temps, vous pouvez ajouter des adresses IP ou des plages IP à une liste blanche. Par défaut, c'est essentiellement uniquement "localhost" :

harden_linux_sshguard_whitelist:
  - "127.0.0.0/8"
  - "::1/128"

Les paquets NTP peuvent également être installés/configurés. C'est optionnel. Par défaut, je recommande d'utiliser systemd-timesyncd. Vous pouvez également utiliser le paquet ntp. Mais openntpd et systemd-timesyncd ont l'avantage de ne pas écouter sur des ports par défaut. Si vous voulez juste garder l'horloge des hôtes synchronisée, cela suffit amplement. Avoir la même heure sur tous vos hôtes est critique pour certains services, par exemple pour la validation des certificats, pour etcd, les bases de données, la cryptographie, etc.

Les options valides pour harden_linux_ntp sont :

openntpd
ntp
systemd-timesyncd

openntpd et systemd-timesyncd ont l'avantage de ne pas écouter sur des ports par défaut comme déjà mentionné. Si vous souhaitez juste garder l'heure des hôtes synchronisée, l'un de ces deux devrait faire le travail. systemd-timesyncd est déjà installé si une distribution utilise systemd (ce qui est généralement vrai pour la plupart des systèmes d'exploitation Linux de nos jours). Donc, aucun paquet supplémentaire n'est nécessaire dans ce cas. Pour activer openntpd, définissez harden_linux_ntp comme suit :

harden_linux_ntp: "openntpd"

Paramètres pour openntpd, ntpd ou systemd-timesyncd (voir le paragraphe suivant). Pour d'autres options, voyez la page de manuel : man 5 ntpd.conf pour ntp et openntpd et man 5 timesyncd.conf pour systemd-timesyncd.

La "clé" ici est une expression régulière d'un paramètre que vous souhaitez remplacer et la valeur est le nom du paramètre + la valeur du paramètre. Par exemple, nous voulons remplacer la ligne servers 0.debian.pool.ntp.org par servers 1.debian.pool.ntp.org. La regex (la clé) serait ^servers 0, ce qui signifie :

"recherchez une ligne dans le fichier de configuration qui commence par server 0 et remplacez toute la ligne par servers 1.debian.pool.ntp.org". De cette manière, chaque paramètre dans le fichier de configuration peut être remplacé par autre chose. Quelques exemples :

harden_linux_ntp_settings:
  "^servers 0": "servers 0.debian.pool.ntp.org"
  "^servers 1": "servers 1.debian.pool.ntp.org"
  "^servers 2": "servers 2.debian.pool.ntp.org"
  "^servers 3": "servers 3.debian.pool.ntp.org"

Veuillez noter : systemd-timesyncd provient de valeurs par défaut raisonnables à la compilation. Donc, normalement, il n'est pas nécessaire de changer la configuration (même pas les serveurs NTP). Donc, les suivants ne sont que des exemples, mais vous n'avez vraiment pas besoin de spécifier harden_linux_ntp_settings pour systemd-timesyncd.

Pour systemd-timesyncd, le fichier de configuration est un peu différent. Dans ce cas, un fichier drop-in systemd pour /etc/systemd/timesyncd.conf sera créé à /etc/systemd/timesyncd.conf.d/.

Exemple pour Debian :

harden_linux_ntp_settings:
  "^#NTP=": "NTP=0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org"

Pour Ubuntu :

harden_linux_ntp_settings:
  "^#NTP=": "NTP=ntp.ubuntu.com"

Pour Archlinux :

harden_linux_ntp_settings:
  "^#NTP=": "NTP=0.arch.pool.ntp.org 1.arch.pool.ntp.org 2.arch.pool.ntp.org 3.arch.pool.ntp.org"

Avec harden_linux_files_to_delete, une liste de fichiers peut être spécifiée qui doit être absente sur l'hôte cible par exemple :

harden_linux_files_to_delete:
  - "/root/.pw"

Si systemd-resolved est utilisé pour la résolution DNS, son comportement peut être ajusté avec harden_linux_systemd_resolved_settings. Par défaut, cette variable n'est pas spécifiée. Une configuration drop-in systemd sera créée dans /etc/systemd/resolved.conf.d/99-override.conf et les paramètres spécifiés y seront ajoutés.

Remarque : Si un paramètre dans /etc/systemd/resolved.conf est déjà défini (par exemple DNS=8.8.8.8), alors définir DNS=9.9.9.9 ci-dessous s'ajoutera. Cela signifie que le paramètre final sera DNS=8.8.8.8 9.9.9.9. Si vous ne le souhaitez pas, vous devez d'abord "définir à vide" la valeur puis ajouter la valeur souhaitée. Par exemple :

harden_linux_systemd_resolved_settings:
  - DNS=
  - DNS=9.9.9.9

Bien que le serveur DNS de Google (8.8.8.8, 8.8.4.4) offre des recherches DNS rapides, c'est bien sûr aussi une possibilité pour Google d'espionner. Donc, utiliser d'autres serveurs DNS devrait au moins être quelque chose à envisager. Mais il y a une autre chose, c'est le chiffrement des requêtes DNS. Une méthode que systemd-resolved prend en charge est DNSOverTLS. Quad9 (9.9.9.9/149.112.112.112) et Cloudflare (1.1.1.1/1.0.0.1) supportent DNSOverTLS.
Donc, les paramètres suivants systemd-resolved configurent les serveurs DNS de Quad9 et Cloudflare pour IPv4 et IPv6. Le paramètre DNSOverTLS=opportunistic utilise DNSOverTLS si le serveur DNS le prend en charge et revient à un DNS non chiffré régulier s'il n'est pas pris en charge (voir aussi resolved.conf.5) :

harden_linux_systemd_resolved_settings:
  - DNS=
  - DNS=9.9.9.9 1.1.1.1 2606:4700:4700::1111 2620:fe::fe
  - FallbackDNS=
  - FallbackDNS=149.112.112.112 1.0.0.1 2620:fe::9 2606:4700:4700::1001
  - DNSOverTLS=
  - DNSOverTLS=opportunistic

De plus, le comportement de mise en cache du gestionnaire de paquets peut être influencé. Par exemple pour Ubuntu :

# Définir sur "false" si le cache des paquets ne doit pas être mis à jour
harden_linux_ubuntu_update_cache: true

# Définir le temps de validité du cache des paquets
harden_linux_ubuntu_cache_valid_time: 3600

Pour Archlinux :

# Définir sur "false" si le cache des paquets ne doit pas être mis à jour
harden_linux_archlinux_update_cache: true

Exemple de Playbook

Si vous avez installé le rôle via ansible-galaxy install githubixx.harden_linux, vous pouvez inclure le rôle dans votre playbook comme dans cet exemple :

- hosts: webservers
  roles:
    - githubixx.harden_linux

Test

Ce rôle dispose d'un petit environnement de test créé avec Molecule, libvirt (vagrant-libvirt) et QEMU/KVM. Veuillez consulter mon article de blog Testing Ansible roles with Molecule, libvirt (vagrant-libvirt) and QEMU/KVM pour savoir comment le configurer. La configuration de test est ici.

Ensuite, exécutez molecule :

molecule converge

Cela mettra en place quelques machines virtuelles (VM) avec différents systèmes d'exploitation Linux supportés et configurer le rôle harden_linux en conséquence. Une petite étape de vérification est également incluse :