[OLD] Recommandations de configuration d'un système GNU/Linux

# Guide de durcissement GNU/Linux selon les recommandations ANSSI #### Introduction Ce guide pratique vise à appliquer méthodiquement les [Recommandations de sécurité relatives à un système GNU/Linux](https://cyber.gouv.fr/publications/recommandations-de-securite-relatives-un-systeme-gnulinux) publiées par l'Agence Nationale de la Sécurité des Systèmes d'Information (ANSSI). L'approche adoptée suit une progression logique basée sur quatre niveaux de durcissement, permettant une mise en œuvre adaptée aux contraintes opérationnelles et aux exigences de sécurité. #### Niveaux de durcissement ANSSI | Niveau | Description | Critère d'application | |--------|-------------|----------------------| | **Minimal (M)** | Mesures fondamentales à appliquer systématiquement | Obligatoire pour tout système exposé | | **Intermédiaire (MI)** | Mesures à mettre en œuvre lorsque les bases sont sécurisées | Recommandé pour la plupart des systèmes | | **Renforcé (MIR)** | Pour systèmes à haute criticité nécessitant un isolement poussé | Selon l'analyse de risque | | **Élevé (MIRE)** | Mesures complexes nécessitant expertise et maintenance continue | Environnements spécialisés avec ressources dédiées | #### Environnement de laboratoire Pour garantir la reproductibilité et la sécurité des tests, nous utilisons un environnement virtualisé avec les spécifications suivantes : #### Configuration VirtualBox - **Système** : Debian 12 "Bookworm" (installation netinst amd64) - **Virtualisation** : Oracle VM VirtualBox 7.0+ - **Réseau** : Mode NAT avec redirection de port (2223 → 22) - **Configuration minimale** : - Pas d'interface graphique - Uniquement SSH et utilitaires système - Partitionnement LVM avec chiffrement complet - 2 Go RAM, 20 Go stockage dynamique #### Justifications architecturales - **Minimalisme** : Réduction maximale de la surface d'attaque initiale - **Chiffrement** : Protection des données au repos (conformité RGPD) - **Isolation** : Environnement virtualisé pour tests sans risque - **Reproductibilité** : Snapshots pour chaque étape significative #### Méthodologie d'application Le processus de durcissement suit un cycle structuré en cinq phases : #### 1. Établissement de la ligne de base - Installation propre du système - Configuration réseau minimale - Création des comptes avec mots de passe robustes #### 2. Audit préliminaire - Analyse des vulnérabilités connues (Debsecan) - Évaluation complète du système (Lynis) - Documentation de l'état initial #### 3. Application incrémentale - Mise en œuvre par niveau de priorité ANSSI - Validation après chaque modification - Tests de régression fonctionnelle #### 4. Vérification et validation - Contrôle de conformité des mesures - Tests de pénétration basique - Documentation des configurations #### 5. Maintenance opérationnelle - Mise à jour régulière - Surveillance continue - Révision périodique #### Installation et configuration initiale #### 1. Préparation de l'environnement #### Téléchargement et création de la VM ```bash # Téléchargement de l'image officielle Lien : https://www.debian.org/CD/netinst/#netinst-stable Fichier : debian-12.x.x-amd64-netinst.iso ## Configuration et installation initiale ``` #### Configuration VirtualBox - **Type** : Linux - **Version** : Debian (64-bit) - **Mémoire** : 2048 Mo - **Stockage** : 20 Go VDI (allocation dynamique) - **Réseau** : Adaptateur 1 : NAT avec redirection de port 2223 (hôte) → 22 (invité) #### Installation Debian minimale **Paramètres d'installation** : Mode : Graphical install. Réseau : DHCP. Utilisateurs : Root : mot de passe généré avec `pwgen -y 16`. Utilisateur standard : avec privilèges sudo. Partitionnement : "Assisté - utiliser tout un disque avec LVM chiffré". > Cela est fait pour éviter un risque de remplissage de partition qui pourrait permettre à l’attaquant de récupérer un accès root. > Une seule partition est choisie pour ces tests exceptionnellement. Dans les faits une partition dédiée au service fourni par le système serait choisie. Sélection des paquets : Décocher toutes les tâches, puis ajouter manuellement : Serveur SSH et Utilitaires système standard. GRUB : Installation sur le disque principal (/dev/sda). #### Point de restauration initial Création du premier snapshot VirtualBox : Nom: snap-00-base-install. Description: "Installation Debian 12 minimale, LVM chiffré, SSH activé, pré-mise à jour". Date: [date d'installation]. #### Évaluation de sécurité initiale #### Audit avec Debsecan Debsecan identifie les vulnérabilités spécifiques à Debian : `sudo apt update && sudo apt install debsecan -y`. Analyse des vulnérabilités corrigeables : `debsecan --suite $(lsb_release --codename --short) --only-fixed --format detail | tee /var/log/debsecan-initial.log`. Résultat attendu : Aucune CVE nécessitant une mise à jour immédiate sur une installation fraîche. #### Audit complet avec Lynis Lynis fournit une analyse détaillée et des recommandations actionnables : `sudo apt install lynis -y`. Audit complet : `sudo lynis audit system --no-colors --quick | tee /var/log/lynis-initial-audit.log`. Génération de rapport HTML : `sudo lynis audit system --report-file /var/log/lynis-initial-report.html`. **Interprétation des résultats typiques** : Le premier rapport Lynis sur une installation minimale Debian révèle généralement : - **Authentification** : Configuration PAM basique, Politique mots de passe absente (Impact: Élevé, Priorité: ) - **Logiciels** : Apt-listbugs manquant, Needrestart absent, Fail2ban non installé (Impact: Moyen, Priorité: ) - **Mémoire** : Core dumps activés, Limites ressources non définies (Impact: Moyen, Priorité: ) - **Réseau** : Serveur DNS unique, Absence de règles firewall (Impact: Élevé, Priorité: ) - **Surveillance** : Scanner malware absent, Journalisation limitée (Impact: Faible, Priorité: ) #### Mise à jour initiale du système Avant toute modification de sécurité, assurer que le système est à jour. Mise à jour complète : `sudo apt update && sudo apt full-upgrade -y && sudo apt autoremove --purge -y`. Nettoyage des paquets obsolètes : `sudo apt clean && sudo apt autoclean`. Redémarrage pour appliquer les mises à jour noyau : `sudo systemctl reboot`. #### Snapshot post-mise à jour Nom: snap-01-system-updated. Description: "Système Debian 12 entièrement mis à jour, prêt pour durcissement". Différences: "Mises à jour de sécurité appliquées, noyau potentiellement mis à jour". #### Connexion et accès distant sécurisé #### Configuration SSH **Architecture réseau** : VirtualBox NAT avec redirection : Hôte Physique (127.0.0.1:2223) → VM Debian (10.0.2.15:22). **Test de connectivité** : Depuis l'hôte physique : `ssh -p 2223 -v utilisateur@localhost`. Vérification des services actifs : `ssh -p 2223 utilisateur@localhost "sudo ss -tulpn | grep LISTEN"`. **Vérification d'isolation** : `ssh -p 2223 utilisateur@localhost "sudo netstat -tulpn"`. Résultat attendu : seul SSH devrait être accessible (tcp 0.0.0.0:22 LISTEN et tcp6 :::22 LISTEN). #### Plan de durcissement structuré #### Outils de suivi et validation - **Debsecan** : Surveillance continue des vulnérabilités - **Lynis** : Audits périodiques et scoring - **Scripts personnalisés** : Vérification automatique des configurations - **Journalisation centralisée** : Traçabilité des modifications > Utile pour le durcissement, Lynis reste un logiciel très intrusif, il est recommandé de le désinstaller avant de passer dans une phase de production. #### Différences environnement virtuel vs physique | Aspect | Environnement VirtualBox | Production physique | Adaptation requise | |--------|-------------------------|---------------------|-------------------| | **BIOS/UEFI** | Configuration limitée | Configuration complète possible | Appliquer sur hôte | | **Secure Boot** | Support émulé limité | Support natif complet | Activer sur matériel | | **Module de plateforme sécurisée (TPM)** | Non disponible | Disponible sur matériel récent | Implémenter en production | | **Accès physique** | Contrôlé virtuellement | Risque physique réel | Mesures supplémentaires | | **Performances** | Limitées par virtualisation | Performances natives | Ajuster les paramètres | #### Prochaines étapes Avec l'environnement de test correctement établi et l'état initial documenté, nous pouvons maintenant procéder à l'application systématique des recommandations ANSSI. Chaque mesure sera abordée avec : Objectif : Contexte, objectif de sécurité et justification. Procédure : Commandes exactes et étapes détaillées. Résultat : Effets sur la sécurité et la fonctionnalité. Vérification : Validation de la mise en œuvre. Production : Adaptations nécessaires pour déploiement réel. La première série de mesures concernera les recommandations de niveau minimal, formant la base indispensable de toute sécurisation système. #### Application des recommandations de l'ANSSI #### Recommandations de niveau minimal : Configuration système #### Comptes d'accès ## R30 Désactiver les comptes utilisateur inutilisés (p36) **Objectif** : Désactiver ou supprimer les comptes utilisateur qui ne sont pas nécessaires au fonctionnement du système, afin de réduire la surface d'attaque. **Niveau ANSSI** : Minimal **Principe associé** : Minimisation **Procédure** : Identifier les comptes inutilisés : `cat /etc/passwd`. Vérifier les derniers logins : `lastlog`. Pour les comptes système non-essentiels, s'assurer qu'ils ont un shell non interactif : `/usr/sbin/nologin` ou `/bin/false`. Désactiver un compte : `usermod -L nom_utilisateur` et `usermod -s /usr/sbin/nologin nom_utilisateur`. Supprimer un compte : `userdel -r nom_utilisateur`. **Résultat** : Tous les comptes système (daemon, bin, sys, etc.) ont `/usr/sbin/nologin` ou `/bin/false`. Un compte applicatif `Debian-exim` était présent (lié à exim4). Action : Suppression de l'utilisateur Debian-exim, car exim4 a été désinstallé. **Vérification** : `getent passwd | grep exim` ne retourne rien. `awk -F: '$7 !~ /(nologin|false)/ {print $1}' /etc/passwd` ne montre que root, sync (compte système légitime présent sur toutes les Debian possédant un shell) et l'utilisateur normal. **Commentaires** : Mesure appliquée. L'installation minimale Debian crée déjà des comptes système sécurisés. La suppression du compte Debian-exim après désinstallation du service correspondant est une bonne pratique. --- ## R31 Utiliser des mots de passe robustes (p37) **Objectif** : Le mot de passe doit être unique, robuste et propre à chaque machine. **Niveau ANSSI** : Minimal **Principe associé** : Authentification forte **Procédure** : Suivre les recommandations : Longueur ≥ 12 caractères. Mélanger minuscules, majuscules, chiffres, caractères spéciaux. Ne pas utiliser de mot de passe déjà utilisé ailleurs. Générer via un outil sécurisé : `pwgen -y 16` (Linux) ou un gestionnaire comme KeePassXC. **Résultat** : Les mots de passe root et utilisateur ont été générés lors de l'installation avec `pwgen -y 16`. **Vérification** : Vérifier la politique avec PAM : `grep -i minlen /etc/pam.d/common-password`. **Commentaires** : Mesure appliquée dès l'installation. Les mots de passe ont été générés aléatoirement avec une longueur suffisante. La politique PAM est configurée pour exiger au moins 12 caractères et 3 classes différentes ([R68](https://hackmd.io/mYu4SFYsT0mppBpJpU9E1g?both#R68-Prot%C3%A9ger-les-mots-de-passe-stock%C3%A9s-p63)). **Source** : Guide de l'ANSSI [« Recommandations relatives à l'authentification multifacteur et aux mots de passe »](https://cyber.gouv.fr/publications/recommandations-relatives-lauthentification-multifacteur-et-aux-mots-de-passe). --- #### Fichiers et répertoires : Droits d'accès ## R53 Éviter les fichiers ou répertoires sans utilisateur ou sans groupe connu (p54) **Objectif** : Les fichiers ou répertoires sans utilisateur ou groupe identifiable par le système doivent être analysés et éventuellement corrigés afin d'avoir un propriétaire ou un groupe connu du système. **Niveau ANSSI** : Minimal **Principe associé** : Intégrité du système de fichiers **Procédure** : La commande suivante permet de lister l'ensemble des fichiers qui n'ont plus d'utilisateur ou de groupe associé : `find / -type f $ -nouser -o -nogroup $ -ls 2>/dev/null`. **Résultat** : La commande exécutée ne retourne aucun résultat sur notre système fraîchement installé et mis à jour. Tous les fichiers ont un propriétaire et un groupe valides. **Vérification** : `find / -type f $ -nouser -o -nogroup $ -ls 2>/dev/null | wc -l` retourne 0. **Commentaires** : Mesure vérifiée et conforme. Aucun fichier orphelin n'a été trouvé. Il est recommandé d'exécuter cette vérification régulièrement, surtout après des opérations de maintenance ou de suppression de comptes utilisateurs. --- ## R54 Activer le sticky bit sur les répertoires inscriptibles (p52) **Objectif** : Protéger les fichiers créés par les utilisateurs dans les répertoires world-writable (ex: `/tmp`), pour qu'ils ne puissent pas être supprimés par d'autres utilisateurs. **Niveau ANSSI** : Minimal **Principe associé** : Séparation des utilisateurs **Procédure** : Vérifier : `find / -type d -perm -0002 ! -perm -1000 -ls 2>/dev/null`. Correction : `chmod +t /tmp` et `chmod +t /var/tmp`. **Résultat** : Les répertoires `/tmp` et `/var/tmp` ont le sticky bit activé : `drwxrwxrwt`. Après correctif, la commande de vérification ne retourne plus rien. **Vérification** : `ls -ld /tmp /var/tmp` montre `drwxrwxrwt` pour les deux répertoires. `find / -type d -perm -0002 ! -perm -1000 -ls 2>/dev/null` ne retourne aucun résultat. **Commentaires** : Mesure appliquée. Le sticky bit est essentiel pour les répertoires temporaires accessibles à tous les utilisateurs. Il empêche la suppression ou le renommage des fichiers appartenant à d'autres utilisateurs. --- ## R56 Éviter l'usage d'exécutables avec les droits spéciaux setuid et setgid (p53) **Objectif** : Limiter strictement le nombre d'exécutables avec les bits setuid et setgid, car ils représentent des vecteurs d'élévation de privilèges potentiels. **Niveau ANSSI** : Minimal **Principe associé** : Moindre privilège **Procédure** : Lister les fichiers : `find / -type f -perm /6000 -ls 2>/dev/null`. Retirer les droits : `chmod u-s <fichier>` pour setuid, `chmod g-s <fichier>` pour setgid. **Actions réalisées** : Conservés (essentiels) : passwd, su, chfn, chsh, gpasswd, mount, umount, ssh-agent, ssh-keysign, dbus-daemon-launch-helper. Désinstallation de exim4. Suppression du setuid sur crontab, chage, expiry : `apt purge exim4 exim4-base exim4-config exim4-daemon-light -y`, `chmod u-s /usr/bin/crontab`, `chmod u-s /usr/bin/chage`, `chmod u-s /usr/bin/expiry`. **Résultat** : Seuls les binaires strictement nécessaires conservent les droits setuid/setgid. **Vérification** : `find / -type f -perm /6000 -ls 2>/dev/null | wc -l` montre un nombre réduit. Vérification manuelle de chaque exécutable restant. **Commentaires** : Mesure appliquée. La réduction des exécutables setuid/setgid est fondamentale. Chaque exécutable avec ces droits doit être justifié. Attention aux impacts fonctionnels. #### Gestion des paquets ## R58 N'installer que les paquets strictement nécessaires (p54) **Objectif** : Minimiser le nombre de paquets installés pour réduire la surface d'attaque, simplifier les mises à jour et la surveillance du système. **Niveau ANSSI** : Minimal **Principe associé** : Minimisation **Procédure** : Obtenir la liste des paquets installés : `dpkg --list`. Supprimer les paquets inutiles avec `apt remove nom_paquet` ou `apt purge nom_paquet`. Utiliser `apt autoremove --purge` pour supprimer les dépendances devenues orphelines. Éviter les méta-paquets qui installent de nombreuses dépendances inutiles. **Résultat** : Installation Debian avec l'option minimale : seulement "SSH server" et "standard system utilities". Pas d'interface graphique, pas de serveurs web, mail ou d'impression. **Vérification** : `dpkg --list | wc -l` montre un nombre réduit de paquets. Un exemple est de vérifier que les paquets communs non nécessaire comme dans notre cas : apache, nginx, mysql, php, exim ou samba, ne sont pas présents avec la commande : `dpkg --list | grep -E "(apache|nginx|mysql|php|exim|samba)"` qui ne retourne rien. **Commentaires** : Mesure appliquée dès l'installation. Une installation minimale réduit la surface d'attaque et facilite la maintenance. --- ## R59 Utiliser des dépôts de paquets de confiance (p55) **Objectif** : N'utiliser que des dépôts de paquets officiels et signés pour garantir l'authenticité et l'intégrité des logiciels installés. **Niveau ANSSI** : Minimal **Principe associé** : Chaîne d'approvisionnement sécurisée **Procédure** : Vérifier les dépôts configurés : `cat /etc/apt/sources.list`. S'assurer que seuls les dépôts Debian officiels sont présents. Vérifier que les dépôts utilisent HTTPS et sont signés avec GPG. **Résultat** : Seul le dépôt Debian officiel est configuré. `/etc/apt/sources.list` contient uniquement les lignes pour `deb.debian.org` avec `main` et `security`. **Vérification** : `cat /etc/apt/sources.list` montre uniquement des URL `deb.debian.org`. `apt-key list` montre les clés GPG Debian officielles. **Commentaires** : Mesure appliquée. L'utilisation exclusive de dépôts officiels Debian garantit que les paquets sont signés et maintenus par l'équipe de sécurité. --- #### Veille et maintenance ## R61 Effectuer des mises à jour régulières (p56) **Objectif** : Maintenir le système à jour avec les correctifs de sécurité pour protéger contre les vulnérabilités connues. **Niveau ANSSI** : Minimal **Principe associé** : Maintenance proactive **Procédure** : Installer unattended-upgrades : `apt install unattended-upgrades apt-listchanges`. Configurer dans `/etc/apt/apt.conf.d/50unattended-upgrades`. Personnaliser dans `/etc/apt/apt.conf.d/52unattended-upgrades-local`. Configurer apt-listchanges pour recevoir des notifications par email. **Résultat** : Unattended-upgrades est installé et configuré pour appliquer automatiquement les mises à jour de sécurité avec `"origin=Debian,codename=$(distro_codename)-security";`. **Vérification** : `systemctl status unattended-upgrades` montre le service actif. Vérifier les logs : `cat /var/log/unattended-upgrades/unattended-upgrades.log`. **Commentaires** : Mesure appliquée. Les mises à jour automatiques de sécurité sont essentielles pour corriger rapidement les vulnérabilités. **Sources** : https://wiki.debian.org/fr/PeriodicUpdates --- #### Recommandations de niveau minimal : Configuration des services ## R62 Désactiver les services non nécessaires (p57) **Objectif** : Désactiver tous les services qui ne sont pas strictement nécessaires au fonctionnement du système pour réduire la surface d'attaque. **Niveau ANSSI** : Minimal **Principe associé** : Minimisation **Procédure** : Lister les services activés : `systemctl list-unit-files --type=service | grep enabled`. Analyser chaque service. Désactiver les services inutiles : `systemctl disable --now nom_service`. Désinstaller les paquets correspondants : `apt purge nom_paquet`. **Résultat** : Services essentiels conservés : SSH, networking, LVM, AppArmor, systemd-timesyncd. Services désactivés : bluetooth, exim4, wpa_supplicant. Cron conservé pour les tâches planifiées. **Actions** : `systemctl disable --now bluetooth.service exim4.service wpa_supplicant.service`. `apt purge exim4 exim4-base exim4-config exim4-daemon-light -y`. **Vérification** : `systemctl list-unit-files --type=service | grep enabled` montre une liste minimale. `ss -tulpn` ne montre que les ports strictement nécessaires (SSH). **Commentaires** : Mesure appliquée. La réduction des services actifs est l'une des mesures de sécurité les plus efficaces. --- #### Service système : Pluggable Authentication Module ## R68 Protéger les mots de passe stockés (p63) **Objectif** : Tout mot de passe doit être protégé par des mécanismes cryptographiques évitant de les exposer en clair à un attaquant. **Niveau ANSSI** : Minimal **Principe associé** : Protection des secrets **Procédure** : PAM peut être configuré pour utiliser yescrypt en ajoutant dans `/etc/pam.d/common-password` : `password required pam_unix.so obscure yescrypt rounds=11`. Si le système ne supporte pas yescrypt, utiliser SHA-512crypt : `password required pam_unix.so obscure sha512 rounds=65536`. **Résultat** : Configuration appliquée avec yescrypt (supporté par Debian 12). Le fichier `/etc/pam.d/common-password` contient la ligne configurée. **Vérification** : Vérifier la configuration : `grep yescrypt /etc/pam.d/common-password`. Tester le hachage d'un nouveau mot de passe et vérifier dans `/etc/shadow` qu'il utilise yescrypt. **Commentaires** : Mesure appliquée. Yescrypt est l'algorithme de hachage moderne recommandé, offrant une bonne résistance aux attaques par force brute. Les rounds=11 fournissent un bon équilibre sécurité/performance. **Source** : Section 4.6 Stockage de mots de passe des [Recommandations relatives à l'authentification multifacteur et aux mots de passe de l'ANSSI](https://cyber.gouv.fr/publications/recommandations-relatives-lauthentification-multifacteur-et-aux-mots-de-passe). #### Service réseau ## R80 Réduire la surface d'attaque des services réseau (p72) **Objectif** : Tous les services réseau doivent être en écoute uniquement sur les interfaces réseau nécessaires, et non sur toutes les interfaces disponibles. **Niveau ANSSI** : Minimal **Principe associé** : Minimisation **Procédure** : Lister les services en écoute réseau : `ss -tulpn` ou `netstat -tulpn`. Pour une analyse plus détaillée, installer et utiliser sockstat : `apt install sockstat` puis `sockstat -l`. Analyser chaque service pour déterminer sur quelle interface il doit écouter. Configurer les services pour qu'ils n'écoutent que sur les interfaces nécessaires (ex: localhost seulement pour les services d'administration). **Résultat** : Sur notre VM minimaliste, seul le service SSH est actif. Il est configuré par défaut pour écouter sur toutes les interfaces (`0.0.0.0:22`). Nous pourrions le restreindre à une interface spécifique si nécessaire. **Vérification** : `ss -tulpn` montre uniquement le service SSH en écoute. `sockstat -l` confirme cette information avec plus de détails (utilisateur, processus, etc.). **Commentaires** : Mesure partiellement appliquée. Le service SSH écoute sur toutes les interfaces car c'est notre seul moyen d'accès à la VM. Dans un environnement de production, on pourrait restreindre SSH à l'interface de management uniquement. Pour les services internes (comme une base de données), ils doivent absolument n'écouter que sur localhost ou l'interface interne. --- #### Contrôle d'accès : modèle traditionnel Unix --- #### Recommandations de niveau intermédiaire : Configuration matérielle #### BIOS/UEFI ## R2 – Configurer le BIOS/UEFI (p13) **Objectif** : Empêcher toute modification non autorisée de la configuration matérielle ou du mode de démarrage de la machine. Une configuration sécurisée du BIOS/UEFI permet de limiter les attaques au niveau du firmware et d'éviter le contournement des mécanismes de sécurité du système d'exploitation. **Niveau ANSSI** : Intermédiaire **Principe associé** : Sécurité physique **Mesures recommandées** : Définir un mot de passe d'administration BIOS/UEFI. Désactiver les périphériques de démarrage inutiles (USB, CD/DVD, PXE). Activer la protection contre l'écriture du BIOS (lorsque disponible). Activer le mode UEFI et désactiver le mode "Legacy/CSM". **Application sur notre environnement** : Dans un environnement VirtualBox, l'accès au BIOS/UEFI est émulé et limité. Ces recommandations ne peuvent donc pas être appliquées directement, mais doivent être mises en œuvre sur un environnement physique réel. **Résultat** : État : 🔶 Non applicable en environnement virtualisé – à implémenter sur machine physique. **Commentaires** : Mesure documentée mais non applicable dans notre TP. La sécurité matérielle est fondamentale car sans elle, les protections logicielles peuvent être contournées. Ces mesures doivent être appliquées sur le système hôte physique ou sur la machine de déploiement final. --- #### Démarrage sécurisé UEFI : Clés préchargées ## R3 – Activer le démarrage sécurisé UEFI (Secure Boot) (p14) **Objectif** : Garantir que seuls les systèmes d'exploitation signés et approuvés puissent démarrer sur la machine. Le Secure Boot UEFI empêche le chargement de bootloaders ou de noyaux modifiés, réduisant les risques d'injection de code malveillant au démarrage. **Niveau ANSSI** : Intermédiaire **Principe associé** : Intégrité du démarrage **Procédure** : Vérifier le mode de démarrage : `ls /sys/firmware/efi`. Si ce répertoire existe, la machine est en mode UEFI. Dans VirtualBox : activer EFI dans les paramètres de la VM (Système → Carte mère → Activer EFI). Vérifier : `dmesg | grep -i efi`. **Résultat** : État : 🔶 Partiellement appliqué. Raison : Nous avons activé EFI dans VirtualBox, mais le Secure Boot n'est pas disponible dans l'émulation VirtualBox. Sur machine physique, il faudrait également : définir un mot de passe administrateur UEFI, activer Secure Boot, désactiver le mode Legacy/CSM. **Vérification** : `ls /sys/firmware/efi` retourne des fichiers, confirmant le mode UEFI. `dmesg | grep -i efi` montre "EFI v2.70 by VirtualBox". **Commentaires** : Mesure partiellement appliquée. Le Secure Boot complet nécessite du matériel réel. Dans notre VM, l'activation d'EFI est déjà un pas vers une configuration moderne. Les bonnes pratiques ANSSI incluent aussi : utiliser des bootloaders signés, interdire le boot sur supports externes, protéger l'accès BIOS/UEFI par mot de passe (R2). --- #### Recommandations de niveau intermédiaire : Configuration du noyau Linux #### Chargeur de démarrage ## R5 – Configurer un mot de passe pour le chargeur de démarrage (GRUB) (p16) **Objectif** : Empêcher un utilisateur non autorisé de modifier les options du noyau ou d'accéder au mode single-user via le chargeur de démarrage. Cette configuration protège l'intégrité du processus de démarrage et empêche une élévation de privilèges locale. **Niveau ANSSI** : Intermédiaire **Principe associé** : Authentification **Procédure** : Générer le mot de passe chiffré : `grub-mkpasswd-pbkdf2 > /root/grub_hash.txt 2>&1`. Extraire le hash : `HASH=$(grep -o 'grub.pbkdf2.sha512.*' /root/grub_hash.txt)`. Ajouter dans `/etc/grub.d/40_custom` : `set superusers="root"` et `password_pbkdf2 root $HASH`. Appliquer : `update-grub`. **Résultat** : État : Appliqué. Mot de passe GRUB configuré et testé. Au redémarrage, la touche 'e' pour éditer les options GRUB demande le mot de passe. **Vérification** : Vérifier le fichier `/etc/grub.d/40_custom` contient les lignes de configuration. Redémarrer et tester que l'édition du menu GRUB demande bien le mot de passe. **Commentaires** : Mesure importante pour la sécurité physique/locale. Empêche un attaquant avec accès physique de démarrer en mode single-user ou de modifier les paramètres kernel. Le mot de passe doit être fort et distinct des autres mots de passe système. Sauvegarde recommandée : `cp /etc/grub.d/40_custom /root/backup_grub_custom`. **Résumé** : | Élément | Statut attendu | |----------|----------------| | Mot de passe GRUB | Configuré | | Fichier modifié | `/etc/grub.d/40_custom` | | Test au démarrage | Mot de passe demandé avant édition du menu | | Outil utilisé | `grub-mkpasswd-pbkdf2` | #### Configuration de la mémoire ## R8 – Paramétrer les options de configuration de la mémoire (p17) **Objectif** : Empêcher la divulgation d'informations sensibles en mémoire (core dumps, adresses mémoire) et activer la randomisation de l'espace d'adressage (ASLR) pour compliquer les attaques de type buffer overflow. **Niveau ANSSI** : Intermédiaire **Principe associé** : Protection mémoire **Procédure** : Désactiver les core dumps pour les processus setuid/setgid : dans `/etc/sysctl.d/99-hardening.conf`, ajouter `fs.suid_dumpable = 0`. Activer l'ASLR : ajouter `kernel.randomize_va_space = 2`. Appliquer : `sysctl --system`. Vérifier : `sysctl fs.suid_dumpable` (doit retourner 0) et `sysctl kernel.randomize_va_space` (doit retourner 2). Vérification pratique de l'ASLR avec un programme C simple qui alloue de la mémoire et affiche son adresse : l'adresse doit changer à chaque exécution. **Résultat** : État : Appliqué. `fs.suid_dumpable = 0` et `kernel.randomize_va_space = 2` sont actifs. Test ASLR confirmé : les adresses mémoire changent à chaque exécution. **Vérification** : `cat /proc/sys/fs/suid_dumpable` retourne 0. `cat /proc/sys/kernel/randomize_va_space` retourne 2. Programme de test C exécuté trois fois montre des adresses différentes. **Commentaires** : Mesure importante. Les core dumps peuvent contenir des données sensibles (mots de passe, clés). L'ASLR est une protection fondamentale contre les exploits mémoire. Ces paramètres sont activés par défaut sur les systèmes modernes mais doivent être vérifiés. Une liste plus complète des options de configuration de la mémoire recommandées par l'ANSSI est donnée page 17. [Recommandations de sécurité relatives à un système GNU/Linux](https://cyber.gouv.fr/publications/recommandations-de-securite-relatives-un-systeme-gnulinux). Ces deux mesures essentielles (désactivation des core dumps + ASLR) sont les points réellement configurables dans notre contexte. Les autres options listées dans le guide relèvent de la compilation du noyau ou sont déjà activées par Debian, donc non modifiables dans notre VM. **Résumé** : | Élément | Paramètre | Valeur attendue | |----------|------------|----------------| | Désactivation des core dumps | fs.suid_dumpable | 0 | | Activation de l'ASLR | kernel.randomize_va_space | 2 | --- #### Configuration du noyau ## R9 – Paramétrer les options de configuration du noyau (p21) **Objectif** : Renforcer la sécurité du noyau Linux en restreignant l'accès à certaines interfaces sensibles et en empêchant les manipulations non autorisées. Ces mesures limitent les possibilités d'escalade de privilèges et d'exploitation locale. **Niveau ANSSI** : Intermédiaire **Principe associé** : Durcissement du noyau **Procédure** : Dans `/etc/sysctl.d/99-hardening.conf`, ajouter : `kernel.kptr_restrict = 2` (interdit l'accès au noyau via /proc/kcore), `kernel.sysrq = 0` (désactive les commandes sysrq), `kernel.dmesg_restrict = 1` (restreint la lecture des messages du noyau). `kernel.modules_disabled = 0` (pour l'instant, désactiver plus tard si possible). Appliquer : `sysctl --system`. Optionnel : `chmod 600 /var/log/kern.log` pour restreindre l'accès aux logs du noyau. **Résultat** : État : Appliqué. Les paramètres sont actifs : `kernel.kptr_restrict = 2`, `kernel.sysrq = 0`, `kernel.dmesg_restrict = 1`. **Vérification** : `sysctl kernel.kptr_restrict` retourne 2. `sysctl kernel.sysrq` retourne 0. `sysctl kernel.dmesg_restrict` retourne 1. Les permissions de `/var/log/kern.log` sont 600. **Commentaires** : Mesure importante pour limiter les fuites d'informations et les attaques locales. `kernel.kptr_restrict=2` empêche la fuite d'adresses mémoire du noyau. `kernel.dmesg_restrict=1` limite la lecture des messages noyau aux root. `kernel.sysrq=0` désactive une fonctionnalité potentiellement dangereuse. **Résumé** : | Élément | Paramètre | Valeur attendue | Description | |----------|------------|----------------|--------------| | Interdiction d'accès direct au noyau | kernel.kptr_restrict | 2 | Empêche la lecture d'adresses mémoire | | Désactivation du sysrq | kernel.sysrq | 0 | Bloque les commandes spéciales système | | Restriction des messages kernel | kernel.dmesg_restrict | 1 | Masque les adresses du noyau | | Accès restreint aux logs | /var/log/kern.log | 600 | Lecture réservée à root | --- #### Configuration des processus ## R11 – Activer et configurer le LSM Yama (p23) **Objectif** : Renforcer la sécurité des processus en limitant l'utilisation de l'appel système `ptrace`, qui permet à un processus de lire ou modifier la mémoire d'un autre. Cela empêche notamment certaines attaques locales ou outils de debug non autorisés. **Niveau ANSSI** : Intermédiaire **Principe associé** : Isolation des processus **Procédure** : Vérifier l'état actuel : `cat /proc/sys/kernel/yama/ptrace_scope`. Valeurs : 0 (désactivé), 1 (recommandé : seul le parent peut tracer ses enfants), 2 (seul root), 3 (complètement désactivé). Activer : dans `/etc/sysctl.d/99-hardening.conf`, ajouter `kernel.yama.ptrace_scope = 1`. Appliquer : `sysctl --system`. **Résultat** : État : Appliqué. `kernel.yama.ptrace_scope = 1` est actif. **Vérification** : `cat /proc/sys/kernel/yama/ptrace_scope` retourne 1. **Commentaires** : Mesure importante contre les attaques locales et outils de débogage malveillants. La valeur 1 est un bon équilibre entre sécurité et fonctionnalité (débogage légitime). Sur les serveurs critiques, on pourrait utiliser la valeur 2 ou 3. **Résumé** : | Élément | Paramètre | Valeur attendue | Description | |----------|------------|----------------|--------------| | Restriction du traçage mémoire | kernel.yama.ptrace_scope | 1 | Restreint l'usage de `ptrace` aux processus enfants du même utilisateur | --- #### Configuration du réseau ## R12 – Paramétrer les options de configuration du réseau IPv4 (p23) **Objectif** : Renforcer la pile réseau IPv4 contre les attaques courantes : spoofing, scans réseau, attaques ICMP, source routing, broadcast storms. **Niveau ANSSI** : Intermédiaire **Principe associé** : Durcissement réseau **Procédure** : Dans `/etc/sysctl.d/99-hardening.conf`, ajouter : `net.ipv4.conf.all.rp_filter = 1` (anti-spoofing), `net.ipv4.conf.all.accept_source_route = 0` (bloque source routing), `net.ipv4.conf.all.accept_redirects = 0` (protection MITM), `net.ipv4.conf.all.send_redirects = 0`, `net.ipv4.icmp_echo_ignore_broadcasts = 1` (protection attaque Smurf), `net.ipv4.icmp_ignore_bogus_error_responses = 1`, `net.ipv4.conf.all.log_martians = 1`. Appliquer : `sysctl --system`. **Résultat** : État : Appliqué. Tous les paramètres IPv4 de durcissement sont actifs. **Vérification** : `sysctl net.ipv4.conf.all.accept_redirects` retourne 0. `sysctl net.ipv4.conf.all.accept_source_route` retourne 0. `sysctl net.ipv4.icmp_echo_ignore_broadcasts` retourne 1. `sysctl net.ipv4.conf.all.rp_filter` retourne 1. **Commentaires** : Mesure essentielle pour tout serveur exposé au réseau. Ces paramètres protègent contre de nombreuses attaques réseau classiques. Doit être appliqué avant toute mise en production. **Résumé** : | Paramètre | Valeur attendue | Objet | |-----------|------------------|-------| | rp_filter | 1 | Protection anti-spoofing | | accept_source_route | 0 | Blocage du source routing | | accept_redirects | 0 | Protection MITM | | send_redirects | 0 | Bonnes pratiques routeur | | icmp_echo_ignore_broadcasts | 1 | Protection attaque Smurf | | log_martians | 1 | Logs des paquets anormaux | --- ## R13 – Désactiver le plan IPv6 (p24) **Objectif** : Désactiver totalement IPv6 lorsqu'il n'est pas utilisé. IPv6 ajouté à un système sans configuration peut exposer des services involontairement, augmenter la surface d'attaque et contourner des règles de filtrage IPv4. **Niveau ANSSI** : Intermédiaire **Principe associé** : Minimisation **Procédure** : Vérifier si IPv6 est utilisé : `ip -6 addr`. Si seulement adresses `fe80::` (link-local), IPv6 n'est pas utilisé. Désactiver dans `/etc/sysctl.d/99-hardening.conf` : `net.ipv6.conf.all.disable_ipv6 = 1`, `net.ipv6.conf.default.disable_ipv6 = 1`, `net.ipv6.conf.lo.disable_ipv6 = 1`. Appliquer : `sysctl --system`. Optionnel : désactiver au démarrage via GRUB : dans `/etc/default/grub`, ajouter `ipv6.disable=1` à `GRUB_CMDLINE_LINUX`, puis `update-grub`. **Résultat** : État : Appliqué. IPv6 est désactivé au niveau noyau. `ip -6 addr` ne montre que les adresses link-local (ou rien si GRUB configuré). **Vérification** : `cat /proc/sys/net/ipv6/conf/all/disable_ipv6` retourne 1. `ip -6 addr` ne montre pas d'adresses globales. **Commentaires** : Mesure importante si IPv6 n'est pas utilisé dans l'organisation. Réduit la surface d'attaque et évite les services écoutant sur IPv6 par défaut. Si IPv6 est utilisé, il faut appliquer les équivalents de R12 pour IPv6. **Résumé** : | Élément | Valeur | Description | |---------|--------|-------------| | disable_ipv6 | 1 | IPv6 désactivé sur toutes les interfaces | | ip -6 addr | vide | Aucune adresse IPv6 globale active | | GRUB ipv6.disable | 1 | IPv6 bloqué dès le démarrage (optionnel) | #### Configuration des systèmes de fichiers ## R14 – Paramétrer les options de configuration des systèmes de fichiers (p25) **Objectif** : Durcir les systèmes de fichiers afin de limiter les possibilités d'exécution de code malveillant, de création de fichiers spéciaux, ou d'élévation de privilèges dans les répertoires accessibles en écriture via les options `noexec`, `nosuid`, `nodev`. **Niveau ANSSI** : Intermédiaire **Principe associé** : Durcissement système de fichiers **Procédure** : Analyser les systèmes de fichiers montés : `mount | column -t`. Modifier `/etc/fstab` pour ajouter : `tmpfs /tmp tmpfs defaults,noexec,nosuid,nodev 0 0`, `tmpfs /var/tmp tmpfs defaults,noexec,nosuid,nodev 0 0`, `tmpfs /dev/shm tmpfs defaults,noexec,nosuid,nodev 0 0`. Appliquer sans redémarrer : `mount -o remount /tmp`, `mount -o remount /var/tmp`, `mount -o remount /dev/shm`. **Résultat** : État : Appliqué. `/tmp`, `/var/tmp`, et `/dev/shm` sont montés en tmpfs avec les options `noexec,nosuid,nodev`. **Vérification** : `mount | grep -E "(tmp|shm)"` montre les options activées. `ls -ld /tmp` montre `drwxrwxrwt`. **Commentaires** : Mesure importante. `noexec` empêche l'exécution de binaires depuis ces répertoires, `nosuid` désactive les bits SUID/SGID, `nodev` interdit les fichiers device. Ces répertoires sont souvent ciblés par les attaquants pour déposer des exécutables malveillants. **Résumé** : | Répertoire | Options | Effet | |------------|---------|--------| | /tmp | noexec,nosuid,nodev | Empêche exécution et élévation de privilège | | /var/tmp | noexec,nosuid,nodev | Idem /tmp | | /dev/shm | noexec,nosuid,nodev | Sécurise la mémoire partagée | --- #### Recommandations de niveau intermédiaire : Configuration système #### Partitionnement ## R28 – Partitionnement type (p35) **Objectif** : Définir un partitionnement conforme aux recommandations ANSSI pour compartimenter les données et isoler les zones critiques, permettant d'appliquer des options de sécurité différentes sur chaque système de fichiers. **Niveau ANSSI** : Intermédiaire **Principe associé** : Séparation des fonctions **Procédure** : Dans notre TP, partitionnement simplifié : Assisté – utiliser tout un disque avec LVM chiffré. Une seule partition logique avec rootfs et swap. `/boot` non chiffré (limitation technique GRUB). Structure : LUKS → LVM → rootfs + swap. **Résultat** : État : 🔶 Partiellement conforme. Raison : Partitionnement simplifié pour le TP, pas de partitions séparées pour `/home`, `/var`, `/usr` comme recommandé par l'ANSSI pour la production. **Vérification** : `lsblk`, `vgdisplay`, `lvdisplay` montent la structure LVM. `mount | column -t` montre les points de montage. **Commentaires** : Pour la production, l'ANSSI recommande : `/boot` (nodev,nosuid,noexec), `/home` (nodev,nosuid), `/var` (nodev), `/tmp` et `/var/tmp` (noexec,nosuid,nodev), `/usr` (nodev). Notre configuration pédagogique simplifie le chiffrement LUKS et les snapshots VirtualBox. **Résumé** : | Élément | TP | Recommandation ANSSI | |---------|-----|------------------------| | Chiffrement | LUKS complet | LUKS complet | | LVM | Oui | Oui | | Partition /boot | Non chiffrée | Non chiffrée | | Partitions séparées | Non | Oui | | Durcissement fin (R14) | Sur tmpfs uniquement | Par partition | --- #### Comptes d'accès ## R32 – Expirer les sessions utilisateur locales (p38) **Objectif** : Limiter les risques liés à l'oubli d'une session ouverte en forçant la déconnexion automatique après une période d'inactivité. **Niveau ANSSI** : Intermédiaire **Principe associé** : Contrôle de session **Procédure** : Dans `/etc/profile`, ajouter : `TMOUT=600`, `readonly TMOUT`, `export TMOUT` (10 minutes). Dans `/root/.bashrc`, ajouter : `TMOUT=300` (5 minutes pour root). Appliquer : `source /etc/profile`. **Résultat** : État : Appliqué. Sessions utilisateur expirent après 10 min d'inactivité, sessions root après 5 min. **Vérification** : `echo $TMOUT` retourne 600 (utilisateurs) ou 300 (root). Tester en laissant un terminal inactif. **Commentaires** : Mesure importante contre les sessions abandonnées. Le `readonly` empêche les utilisateurs de modifier TMOUT. Doit être ajusté selon la sensibilité du poste. **Résumé** : | Élément | Valeur | Description | |--------|--------|-------------| | TMOUT global | 600 | Déconnexion après 10 min | | TMOUT root | 300 | Déconnexion après 5 min | | readonly TMOUT | Oui | Empêche la modification | --- ## R33 – Assurer l'imputabilité des actions d'administration (p38) **Objectif** : Garantir que toutes les actions d'administration sont traçables et imputables à un utilisateur identifié. Root ne doit pas être utilisé directement. **Niveau ANSSI** : Intermédiaire **Principe associé** : Prouvabilité **Procédure** : Désactiver connexion root SSH : dans `/etc/ssh/sshd_config`, `PermitRootLogin no`. Créer groupe admin : `groupadd admin`. Ajouter utilisateur : `usermod -aG admin utilisateur`. Configurer sudo : dans `/etc/sudoers.d/admin`, `%admin ALL=(ALL) ALL`. Activer logs sudo : dans `/etc/sudoers`, `Defaults log_output` et `Defaults logfile="/var/log/sudo.log"`. Restreindre `su` : dans `/etc/pam.d/su`, `auth required pam_wheel.so`. **Résultat** : État : Appliqué. Connexion root SSH interdite, administration via sudo avec compte nominatif, logs complets, `su` restreint au groupe wheel. **Vérification** : `sudo -l` fonctionne. `tail /var/log/sudo.log` montre les actions. `ssh root@localhost` échoue. **Commentaires** : Mesure essentielle pour l'audit et la traçabilité. Chaque action admin doit être attribuable à une personne. --- ## R34 – Désactiver les comptes de service (p40) **Objectif** : Désactiver ou supprimer les comptes de service inutilisés. Les comptes système doivent utiliser un shell non interactif. **Niveau ANSSI** : Intermédiaire **Principe associé** : Minimisation **Procédure** : Audit des comptes : `cat /etc/passwd`. Désinstaller services inutiles : `apt purge exim4...`. Supprimer compte associé : `deluser --system Debian-exim`. Vérifier shells non interactifs : `awk -F: '$7 != "/usr/sbin/nologin" && $7 != "/bin/false"' /etc/passwd`. **Résultat** : État : Appliqué. Compte Debian-exim supprimé. Tous les comptes système ont un shell non interactif. **Vérification** : `getent passwd | grep exim` vide. Commande awk ne retourne que root et utilisateur normal. **Commentaires** : Mesure de base. Les comptes de service inactifs sont des cibles potentielles. --- ## R35 – Utiliser des comptes de service uniques et exclusifs (p40) **Objectif** : Chaque service métier doit disposer de son propre compte système dédié pour éviter le partage d'identifiants et limiter l'impact d'une compromission. **Niveau ANSSI** : Intermédiaire **Principe associé** : Séparation des privilèges **Procédure** : Pour chaque service applicatif (nginx, mysql, etc.), créer un compte dédié : `adduser --system --group --no-create-home nom_service`. Définir permissions restrictives : `chown -R nom_service:nom_service /chemin/data`, `chmod 750 /chemin/data`. **Résultat** : État : Conforme (pas de service applicatif installé). Raison : Installation minimale Debian sans services métier. **Vérification** : `cat /etc/passwd` ne montre que comptes système standards. **Commentaires** : Mesure à appliquer lors de l'ajout de tout service applicatif. Empêche l'exploitation en chaîne si un service est compromis. --- ## R39 – Modifier les directives de configuration sudo (p44) **Objectif** : Activer des directives sudo sécurisées par défaut pour renforcer l'exécution de commandes privilégiées. **Niveau ANSSI** : Intermédiaire **Principe associé** : Durcissement sudo **Procédure** : Avec `visudo`, ajouter : `Defaults noexec,requiretty,use_pty,umask=0027` et `Defaults ignore_dot,env_reset`. Ces directives s'appliquent globalement. Peuvent être surchargées par utilisateur/groupe. **Résultat** : État : Appliqué. Directives de sécurité sudo activées. **Vérification** : `sudo -l` montre les restrictions. `visudo -c` valide la syntaxe. **Commentaires** : `noexec` empêche l'exécution de sous-processus, `requiretty` impose un TTY, `use_pty` force un pseudo-TTY, `umask=0027` restreint les permissions, `ignore_dot` ignore le "." dans PATH, `env_reset` réinitialise l'environnement. --- ## R40 – Utiliser des utilisateurs cibles non-privilégiés pour les commandes sudo (p44) **Objectif** : Les utilisateurs cibles d'une règle sudo doivent, autant que possible, être des utilisateurs non privilégiés (pas root) pour limiter les risques d'escalade. **Niveau ANSSI** : Intermédiaire **Principe associé** : Moindre privilège **Procédure** : Éviter `(root)` comme utilisateur-cible. Utiliser des comptes dédiés : `(www-data)`, `(backup)`, etc. Pour l'édition de fichiers, utiliser `sudoedit` plutôt qu'un éditeur direct. **Résultat** : État : Appliqué. Notre configuration sudo utilise des cibles appropriées. `sudoedit` est utilisé pour l'édition sécurisée. **Vérification** : `sudo -l` montre les règles avec utilisateurs-cibles non-root. **Commentaires** : Empêche le contournement via des éditeurs (vi, nano) qui pourraient ouvrir un shell root. `sudoedit` copie le fichier temporairement avec les droits utilisateur. --- ## R42 – Bannir les négations dans les spécifications sudo (p45) **Objectif** : Interdire les négations dans les règles sudoers car elles créent des ambiguïtés dangereuses dans l'évaluation des commandes autorisées. **Niveau ANSSI** : Intermédiaire **Principe associé** : Clarté des politiques **Procédure** : Ne jamais utiliser `!` dans sudoers. Définir explicitement ce qui est autorisé, de manière positive. **Résultat** : État : Appliqué. Aucune négation dans notre configuration sudo. **Vérification** : `grep "!" /etc/sudoers /etc/sudoers.d/*` ne retourne rien. **Commentaires** : Les négations sont dangereuses car le globbing shell peut créer des interprétations ambiguës. Toujours spécifier positivement les commandes autorisées. --- ## R43 – Préciser les arguments dans les spécifications sudo (p45) **Objectif** : Toutes les commandes dans sudoers doivent préciser exactement les arguments autorisés. Éviter le wildcard `*`. Utiliser `""` si aucun argument. **Niveau ANSSI** : Intermédiaire **Principe associé** : Précision des autorisations **Procédure** : Spécifier les arguments autorisés : `dmesg ""` pour interdire les arguments. Éviter `*`. Pour les commandes nécessitant des arguments spécifiques, les lister explicitement. **Résultat** : État : Appliqué. Notre configuration sudo spécifie précisément les commandes autorisées. **Vérification** : `sudo -l` montre les commandes avec leurs restrictions d'arguments. **Commentaires** : Empêche le détournement de commandes via des arguments arbitraires (ex: `dmesg --file=/etc/shadow`). --- ## R44 – Éditer les fichiers de manière sécurisée avec sudo (p46) **Objectif** : Utiliser `sudoedit` pour l'édition de fichiers plutôt qu'un éditeur classique via sudo, pour empêcher l'ouverture de shells root et l'accès arbitraire aux fichiers. **Niveau ANSSI** : Intermédiaire **Principe associé** : Sécurité de l'édition **Procédure** : Toujours utiliser `sudoedit /chemin/fichier` au lieu de `sudo vi/nano /chemin/fichier`. `sudoedit` copie temporairement le fichier avec les droits utilisateur, ouvre l'éditeur sans privilèges, puis remplace le fichier original. **Résultat** : État : Appliqué. `sudoedit` est la méthode standard pour l'édition. **Vérification** : Tester `sudoedit /etc/hosts` fonctionne. `sudo vi /etc/hosts` est interdit. **Commentaires** : Essentiel pour empêcher l'escalade via des éditeurs. `sudoedit` est sécurisé par design. --- #### Fichiers et répertoires ## R50 – Restreindre les droits d'accès aux fichiers et aux répertoires sensibles (p50) **Objectif** : Les fichiers et répertoires sensibles ne doivent être lisibles que par les utilisateurs ayant le strict besoin d'en connaître. **Niveau ANSSI** : Intermédiaire **Principe associé** : Moindre privilège **Procédure** : Fichiers système sensibles : `chown root:root`, `chmod 600`. Fichiers applicatifs : `chown utilisateur:groupe_dédié`, `chmod 640`. Vérifier régulièrement : `ls -l /etc/shadow /etc/passwd /etc/sudoers`. **Résultat** : État : Appliqué. Permissions des fichiers sensibles vérifiées et corrigées si nécessaire. **Vérification** : `ls -l /etc/shadow` montre `-rw-r----- root:shadow`. `ls -l /etc/passwd` montre `-rw-r--r-- root:root`. **Commentaires** : Appliquer dès l'installation. Protège contre la lecture non autorisée de secrets. --- ## R52 – Restreindre les accès aux sockets et aux pipes nommées (p52) **Objectif** : Protéger les sockets et pipes nommées via des répertoires aux droits strictement contrôlés. **Niveau ANSSI** : Intermédiaire **Principe associé** : Sécurisation IPC **Procédure** : Ne jamais créer de sockets dans `/tmp` ou `/var/tmp`. Utiliser des répertoires dédiés avec permissions restreintes. Vérifier : `sockstat`, `ss -xp`, `ipcs`, `ls /dev/shm`, `lsof`. **Résultat** : État : Vérifié. Aucune socket dans les répertoires temporaires. `/dev/shm` sécurisé via R14. **Vérification** : `find /tmp /var/tmp -type s 2>/dev/null` ne retourne rien. **Commentaires** : Les sockets publiques sont vulnérables au détournement et à l'injection. --- ## R55 – Séparer les répertoires temporaires des utilisateurs (p55) **Objectif** : Chaque utilisateur ou application doit posséder son propre répertoire temporaire exclusif. **Niveau ANSSI** : Intermédiaire **Principe associé** : Isolement utilisateur **Procédure** : Utiliser PAM modules `pam_mktemp` et `pam_namespace` pour créer des répertoires temporaires privés. Pour fichiers partagés, créer un groupe dédié avec droits d'écriture exclusifs. **Résultat** : État : 🔶 Partiellement appliqué. `/tmp` est partagé mais protégé par sticky bit (R54). Pas de configuration PAM avancée. **Vérification** : `find / -type f -perm -0002 -ls 2>/dev/null` liste les fichiers world-writable. **Commentaires** : Pour les environnements multi-utilisateurs, cette mesure est importante pour prévenir les attaques entre utilisateurs. #### Recommandations de niveau intermédiaire : Configuration des services ## R63 – Désactiver les fonctionnalités des services non essentielles (p58) **Objectif** : Limiter les fonctionnalités des services démarrés au strict nécessaire, et désactiver les Linux capabilities inutiles qui pourraient permettre une élévation de privilèges. **Niveau ANSSI** : Intermédiaire **Principe associé** : Minimisation **Procédure** : Désinstaller les services non essentiels : `apt purge exim4 bind9 ntp` si non utilisés. Vérifier les capabilities actives : `find / -type f -perm /111 -exec getcap {} \; 2>/dev/null`. Retirer les capabilities inutiles : `setcap -r /chemin/vers/exécutable`. Pour les services systemd, utiliser `CapabilityBoundingSet=` pour limiter les capabilities. **Résultat** : État : Appliqué. Aucun service SMTP, DNS, ou NTP installé. Vérification des capabilities ne montre que celles essentielles (comme `cap_net_bind_service` pour les services réseau). **Vérification** : `dpkg -l | grep -E "(exim|bind|ntp)"` ne retourne rien. `getcap /usr/bin/ping` montre `cap_net_raw+ep` (nécessaire). **Commentaires** : Les Linux capabilities (41 au total) divisent les privilèges root. 19 permettent trivialement d'obtenir root. Doivent être strictement contrôlées. --- #### Services système ## R67 – Sécuriser les authentifications distantes par PAM (p64) **Objectif** : Garantir que les authentifications distantes via PAM utilisent des canaux sécurisés (chiffrement, authentification serveur, anti-rejeu). **Niveau ANSSI** : Intermédiaire **Principe associé** : Authentification sécurisée **Procédure** : Pour les modules distants (`pam_ldap`, `pam_krb5`, `pam_mysql`), configurer TLS/SSL. Exemple LDAPS : dans `/etc/ldap/ldap.conf`, `URI ldaps://serveur` et `TLS_REQCERT demand`. Utiliser des modules PAM de sécurité : `pam_faillock` (blocage après échecs), `pam_pwquality` (complexité mots de passe), `pam_wheel` (restriction `su`). **Résultat** : État : 🔶 Non applicable. Raison : Pas d'authentification distante configurée (annuaire LDAP, Kerberos). Modules PAM locaux sécurisés (R68). **Vérification** : `grep -r "pam_ldap\|pam_krb5" /etc/pam.d/` ne retourne rien. **Commentaires** : Si authentification distante, impératif d'utiliser TLS et d'authentifier le serveur. Les mots de passe en clair sur le réseau sont interdits. --- ## R69 – Sécuriser les accès aux bases utilisateur distantes (p65) **Objectif** : Configurer NSS (Name Service Switch) pour établir des liaisons sécurisées avec les bases utilisateur distantes (LDAP, etc.), avec chiffrement et authentification. **Niveau ANSSI** : Intermédiaire **Principe associé** : Sécurité des annuaires **Procédure** : Pour LDAP, configurer `/etc/ldap/ldap.conf` avec `URI ldaps://...` et `TLS_CACERT`. Pour `nslcd`, configurer `/etc/nslcd.conf` avec `uri ldaps://...`, `ssl on`, `tls_reqcert demand`. Utiliser un compte dédié avec droits minimum (`binddn`). Ne jamais transmettre en clair. **Résultat** : État : 🔶 Non applicable. Raison : Pas d'annuaire utilisateur distant configuré sur notre VM. Utilisateurs locaux uniquement. **Vérification** : `getent passwd` ne montre que les comptes locaux. Pas de service `nslcd` ou `sssd` actif. **Commentaires** : Si utilisation d'un annuaire, obligation de chiffrement (LDAPS/StartTLS) et d'authentification mutuelle. Le compte de lecture doit avoir des droits restrictifs. --- ## R70 – Durcissement du noyau et des interfaces réseau (p66) **Objectif** : Renforcer la pile réseau contre le spoofing et les attaques ICMP (redirects). **Niveau ANSSI** : Intermédiaire **Principe associé** : Durcissement réseau **Procédure** : Dans `/etc/sysctl.d/99-hardening.conf`, ajouter : `net.ipv4.conf.all.rp_filter = 1`, `net.ipv4.conf.default.rp_filter = 1` (anti-spoofing). `net.ipv4.conf.all.accept_redirects = 0`, `net.ipv4.conf.default.accept_redirects = 0` (bloque ICMP redirects). Appliquer : `sysctl --system`. **Résultat** : État : Appliqué. Ces paramètres font partie de R12 (IPv4 durcissement) déjà appliqué. **Vérification** : `sysctl net.ipv4.conf.all.rp_filter` retourne 1. `sysctl net.ipv4.conf.all.accept_redirects` retourne 0. **Commentaires** : `rp_filter` (Reverse Path Filtering) empêche le spoofing d'adresses IP. `accept_redirects=0` bloque les tentatives de redirection de route ICMP (attaque MITM). --- #### Messagerie ## R74 – Durcir le service de messagerie locale (p69) **Objectif** : Configurer le service de messagerie locale pour n'accepter que les messages à destination de comptes locaux, et uniquement sur l'interface loopback, les connexions distantes au service de messagerie doivent être rejetées. **Niveau ANSSI** : Intermédiaire **Principe associé** : Minimisation service **Procédure** : Si MTA installé (Postfix, Exim), configurer pour n'écouter que sur `127.0.0.1:25`. Ne pas relayer de messages externes. Désactiver les fonctionnalités inutiles. Utiliser un MTA léger comme `ssmtp` ou `msmtp` si seul l'envoi local est nécessaire. **Résultat** : État : Conforme. Aucun service de messagerie installé (`exim4` désinstallé). Les notifications cron (si activées) utiliseraient un MTA local minimal. **Vérification** : `ss -tulpn | grep :25` ne retourne rien. `dpkg -l | grep -i mail` ne montre pas de MTA. **Commentaires** : Beaucoup de distributions installent un MTA par défaut (Exim sur Debian). Il doit être désinstallé ou durci si non utilisé. Un MTA mal configuré peut devenir un relais ouvert. --- ## R75 – Configurer un alias de messagerie des comptes de service (p70) **Objectif** : Rediriger les emails des comptes de service (root, cron, etc.) vers une boîte administrateur centralisée pour ne perdre aucune alerte. **Niveau ANSSI** : Intermédiaire **Principe associé** : Centralisation des alertes **Procédure** : Éditer `/etc/aliases` : `root: admin@domaine`, `postmaster: root`, `cron: admin@domaine`. Appliquer : `newaliases`. Configurer le MTA pour envoyer vers le serveur de messagerie de l'organisation. **Résultat** : État : 🔶 Non applicable. Raison : Pas de MTA installé, pas de serveur de messagerie d'organisation défini dans notre TP. **Vérification** : `/etc/aliases` peut être préconfiguré mais sans effet sans MTA. **Commentaires** : Essentiel en production pour recevoir les alertes système (cron, logs, surveillance). L'alias root doit absolument être redirigé vers un compte administrateur réel et surveillé. -- ## R21 – Paramétrer les options de compilation pour les plugins du compilateur (p29) **Objectif** : Activer des plugins GCC qui ajoutent des protections supplémentaires lors de la compilation du noyau, renforçant ainsi la sécurité contre diverses classes d'attaques. **Niveau ANSSI** : Renforcé **Principe associé** : Durcissement de la compilation **Niveau Lynis** : Compilation noyau **Source** : ANSSI p.29 **Procédure** : Ces options nécessitent la recompilation du noyau avec des plugins spécifiques de GCC. Options à activer dans la configuration du noyau : `CONFIG_GCC_PLUGINS=y` : Active le support des plugins GCC. `CONFIG_GCC_PLUGIN_LATENT_ENTROPY=y` : Ajoute une source d'entropie latente pour améliorer l'ASLR. `CONFIG_GCC_PLUGIN_STACKLEAK=y` : Nettoie la pile lors des appels système pour éviter les fuites d'informations. `CONFIG_GCC_PLUGIN_STRUCTLEAK=y` : Force l'initialisation des structures pour éviter les fuites de données. `CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL=y` : Étend STRUCTLEAK à toutes les structures passées par référence. `CONFIG_GCC_PLUGIN_RANDSTRUCT=y` : Randomise la disposition des structures du noyau pour compliquer les exploits. Prérequis : GCC version 4.5 ou supérieure avec support des plugins. Étapes de mise en œuvre : Installer les dépendances : `apt install gcc-plugin-dev`. Récupérer les sources du noyau : `apt source linux-source`. Configurer avec les plugins activés : `make menuconfig` → naviguer dans "General architecture-dependent options" → "GCC plugins". Compiler avec les plugins : `make -j$(nproc)`. Installer le noyau compilé : `make modules_install && make install`. Mettre à jour GRUB : `update-grub`. **Vérification** : Vérifier la présence des protections : `dmesg | grep -i "stackleak\|structleak\|randstruct"`. Vérifier la version de GCC : `gcc --version`. **Résultat** : État : Non appliqué. Raison : Complexité technique élevée, nécessité de maintenir un noyau recompilé avec des plugins spécifiques. Le noyau Debian standard n'active pas ces plugins par défaut. **Commentaires** : Mesure écartée en raison de sa complexité. Ces plugins apportent des protections avancées mais : 1) Augmentent significativement la taille du noyau, 2) Peuvent affecter les performances, 3) Nécessitent un suivi rigoureux des mises à jour. Le projet linux-hardened inclut certains de ces plugins pré-activés, ce qui pourrait être une alternative pour des déploiements critiques. Impact sécurité : Élevé contre les attaques par fuite d'informations et les exploits ciblant la mémoire. ## R22 – Paramétrer les options de compilation pour la pile réseau (p30) **Objectif** : Configurer les options de compilation du noyau pour renforcer la sécurité de la pile réseau, notamment en désactivant IPv6 si non utilisé. **Niveau ANSSI** : Intermédiaire **Principe associé** : Minimisation **Niveau Lynis** : Réseau IPv6 **Source** : ANSSI p.30 **Procédure** : Options de compilation à configurer lors de la recompilation du noyau : `CONFIG_IPV6=n` : Désactive complètement le support IPv6 dans le noyau. `CONFIG_SYN_COOKIES=y` : Active la protection contre les attaques SYN flood. Pour désactiver IPv6 : Si IPv6 n'est pas utilisé dans l'organisation, le désactiver au niveau de la compilation réduit la surface d'attaque. Étapes : Récupérer les sources : `apt source linux-source`. Modifier la configuration : `make menuconfig`, aller dans "Networking support" → "Networking options" → "The IPv6 protocol" → désactiver. Ou éditer directement .config : `CONFIG_IPV6=n`. Compiler : `make -j$(nproc)`. Installer : `make modules_install && make install`. Mettre à jour GRUB : `update-grub`. Alternative sans recompilation : Désactiver IPv6 via sysctl (R13) et GRUB (ipv6.disable=1). **Vérification** : Vérifier qu'IPv6 est désactivé : `ip -6 addr show` doit être vide. Vérifier dans la configuration du noyau : `zcat /proc/config.gz | grep IPV6`. **Résultat** : État : IPv6 désactivé via sysctl (R13). Raison : La désactivation via sysctl est suffisante pour notre TP, évitant la complexité d'une recompilation. **Commentaires** : Mesure partiellement appliquée via R13. La désactivation complète d'IPv6 à la compilation est plus robuste car empêche tout chargement de modules IPv6. Cependant, pour notre environnement de test, la désactivation via sysctl est acceptable. La protection SYN cookies est généralement activée par défaut dans les noyaux modernes. Impact sécurité : Moyen (réduction de surface d'attaque). ## R23 – Paramétrer les options de compilation pour divers comportements du noyau (p30) **Objectif** : Désactiver des fonctionnalités du noyau non nécessaires qui augmentent inutilement la surface d'attaque. **Niveau ANSSI** : Intermédiaire **Principe associé** : Minimisation **Niveau Lynis** : Compilation noyau **Source** : ANSSI p.30 **Procédure** : Options de compilation à désactiver si elles ne sont pas absolument nécessaires : `CONFIG_KEXEC=n` : Interdit l'exécution d'une nouvelle image noyau à chaud (kexec). `CONFIG_HIBERNATION=n` : Interdit le passage en mode hibernation. `CONFIG_BINFMT_MISC=n` : Désactive le support de format binaire arbitraire. `CONFIG_LEGACY_PTYS=n` : Impose l'utilisation des ptys modernes (devpts). `CONFIG_MODULES=n` : Désactive complètement le support des modules noyau (si possible). Étapes : Récupérer les sources : `apt source linux-source`. Configurer : `make menuconfig`, désactiver ces options dans les sections correspondantes. Compiler : `make -j$(nproc)`. Installer : `make modules_install && make install`. Mettre à jour GRUB : `update-grub`. **Vérification** : Vérifier les options désactivées : `zcat /proc/config.gz | grep -E "(KEXEC|HIBERNATION|BINFMT_MISC|LEGACY_PTYS|MODULES)"`. **Résultat** : État : Non appliqué (noyau Debian standard). Raison : Ces options sont généralement activées dans le noyau Debian pour la compatibilité. Désactiver kexec et hibernation réduit les risques mais peut limiter certaines fonctionnalités légitimes. **Commentaires** : Mesure écartée. Bien que ces désactivations réduisent la surface d'attaque, elles peuvent affecter la fonctionnalité dans certains cas d'usage. Par exemple, kexec est utilisé pour les mises à jour rapides du noyau, et hibernation peut être nécessaire sur les portables. Dans un environnement serveur strict, ces désactivations sont pertinentes. Impact sécurité : Moyen (réduction surface d'attaque). ## R24 – Paramétrer les options de compilation spécifiques aux architectures 32 bits (p31) **Objectif** : Configurer des options de sécurité spécifiques aux architectures 32 bits (x86) pour renforcer la protection mémoire et l'ASLR. **Niveau ANSSI** : Intermédiaire **Principe associé** : Protection mémoire **Niveau Lynis** : Compilation noyau **Source** : ANSSI p.31 **Procédure** : Options de compilation pour architectures x86 32 bits : `CONFIG_HIGHMEM64G=y` : Active le support des extensions d'adresse physique, prérequis pour le bit NX. `CONFIG_X86_PAE=y` : Active Physical Address Extension. `CONFIG_DEFAULT_MMAP_MIN_ADDR=65536` : Interdit l'utilisation d'adresses mémoire en dessous de 64 Ko (protection contre les null pointer dereference). `CONFIG_RANDOMIZE_BASE=y` : Rend non prédictible l'adresse de base du noyau (KASLR). Étapes pour architecture 32 bits : Configurer le noyau pour i386 : `make ARCH=i386 menuconfig`. Activer les options dans "Processor type and features". Compiler : `make ARCH=i386 -j$(nproc)`. Installer le noyau 32 bits. Note : Pour notre VM en amd64 (64 bits), ces options ne sont pas pertinentes. **Vérification** : Sur système 32 bits : `zcat /proc/config.gz | grep -E "(HIGHMEM64G|X86_PAE|DEFAULT_MMAP_MIN_ADDR|RANDOMIZE_BASE)"`. **Résultat** : État : Non applicable. Raison : Notre VM est en architecture amd64 (64 bits), ces options sont spécifiques aux systèmes 32 bits. **Commentaires** : Mesure non applicable à notre environnement. Ces protections sont importantes pour les systèmes 32 bits encore en service, notamment pour activer le bit NX (No eXecute) qui marque certaines pages mémoire comme non exécutables. Pour les systèmes 64 bits, des options équivalentes existent (R25). Impact sécurité : Élevé pour systèmes 32 bits. ## R25 – Paramétrer les options de compilation spécifiques aux architectures x86_64 bits (p31) **Objectif** : Configurer des options de sécurité spécifiques aux architectures x86_64 bits pour renforcer la protection mémoire, l'ASLR et contre les attaques matérielles. **Niveau ANSSI** : Intermédiaire **Principe associé** : Protection mémoire **Niveau Lynis** : Compilation noyau **Source** : ANSSI p.31 **Procédure** : Options de compilation pour architectures x86_64 bits : `CONFIG_X86_64=y` : Active le mode complet 64 bits. `CONFIG_DEFAULT_MMAP_MIN_ADDR=65536` : Interdit l'utilisation d'adresses mémoire en dessous de 64 Ko (protection contre les null pointer dereference). `CONFIG_RANDOMIZE_BASE=y` : Rend non prédictible l'adresse de base du noyau (KASLR). `CONFIG_RANDOMIZE_MEMORY=y` : Rend non prédictible l'adresse à laquelle les composants du noyau sont exposés. `CONFIG_PAGE_TABLE_ISOLATION=y` : Contre-mesure à l'attaque Meltdown (PTI). `CONFIG_IA32_EMULATION=n` : Désactive la rétro-compatibilité 32 bits (réduit la surface d'attaque). `CONFIG_MODIFY_LDT_SYSCALL=n` : Interdit la surcharge par processus de la Local Descriptor Table. Étapes pour notre VM amd64 : Récupérer les sources : `apt source linux-source`. Configurer : `make menuconfig`, activer ces options dans "Processor type and features". Compiler : `make -j$(nproc)`. Installer : `make modules_install && make install`. Mettre à jour GRUB : `update-grub`. **Vérification** : Vérifier les options activées : `zcat /proc/config.gz | grep -E "(RANDOMIZE_BASE|RANDOMIZE_MEMORY|PAGE_TABLE_ISOLATION|IA32_EMULATION)"`. **Résultat** : État : Partiellement appliqué via noyau Debian standard. Raison : Le noyau Debian inclut déjà la plupart de ces options (KASLR, PTI). La désactivation de IA32_EMULATION pourrait casser la compatibilité avec certains logiciels 32 bits. **Commentaires** : Mesure partiellement appliquée. Les protections contre Meltdown (PTI) et l'ASLR avancée (RANDOMIZE_MEMORY) sont généralement activées dans les noyaux modernes. La désactivation de la compatibilité 32 bits est intéressante pour les serveurs purs 64 bits mais peut poser problème si des applications 32 bits doivent être exécutées. Impact sécurité : Élevé contre les attaques par canaux auxiliaires et les exploits mémoire. ## R26 – Paramétrer les options de compilation spécifiques aux architectures ARM (p32) **Objectif** : Configurer des options de sécurité spécifiques aux architectures ARM 32 bits pour renforcer la protection mémoire et l'ASLR. **Niveau ANSSI** : Intermédiaire **Principe associé** : Protection mémoire **Niveau Lynis** : Compilation noyau **Source** : ANSSI p.32 **Procédure** : Options de compilation pour architectures ARM : `CONFIG_DEFAULT_MMAP_MIN_ADDR=32768` : Interdit l'utilisation d'adresses mémoire en dessous de 32 Ko (protection contre les null pointer dereference). `CONFIG_VMSPLIT_3G=y` : Maximise la taille de la mémoire virtuelle des processus (et l'ASLR afférent). `CONFIG_STRICT_MEMORY_RWX=y` : Interdit les mappings mémoire en lecture-écriture-exécution simultanées. `CONFIG_CPU_SW_DOMAIN_PAN=y` : Interdit les accès par le noyau à la mémoire utilisateur (équivalent à SMAP sur x86_64). `CONFIG_OABI_COMPAT=n` : Désactive la compatibilité avec l'ancienne ABI ARM (dangereuse). Étapes pour architecture ARM : Configurer pour ARM : `make ARCH=arm menuconfig`. Activer les options dans "Kernel Features" et "Boot options". Compiler : `make ARCH=arm -j$(nproc)`. Installer le noyau ARM. Note : Pour notre VM x86_64, ces options ne sont pas pertinentes. **Vérification** : Sur système ARM : `zcat /proc/config.gz | grep -E "(DEFAULT_MMAP_MIN_ADDR|VMSPLIT|STRICT_MEMORY_RWX|CPU_SW_DOMAIN_PAN)"`. **Résultat** : État : Non applicable. Raison : Notre VM est en architecture x86_64, ces options sont spécifiques aux systèmes ARM. **Commentaires** : Mesure non applicable à notre environnement. Ces protections sont cruciales pour les systèmes embarqués et IoT basés sur ARM, particulièrement pour les appareils avec ressources limitées. La désactivation de OABI_COMPAT est importante car cette ancienne ABI présente des vulnérabilités connues. Impact sécurité : Élevé pour systèmes ARM. ## R27 – Paramétrer les options de compilation spécifiques aux architectures ARM 64 bits (p32) **Objectif** : Configurer des options de sécurité spécifiques aux architectures ARM 64 bits (ARM64/AArch64) pour renforcer la protection mémoire, l'ASLR et contre les attaques matérielles. **Niveau ANSSI** : Intermédiaire **Principe associé** : Protection mémoire **Niveau Lynis** : Compilation noyau **Source** : ANSSI p.32 **Procédure** : Options de compilation pour architectures ARM 64 bits : `CONFIG_DEFAULT_MMAP_MIN_ADDR=32768` : Interdit l'utilisation d'adresses mémoire en dessous de 32 Ko (protection contre les null pointer dereference). `CONFIG_RANDOMIZE_BASE=y` : Rend non prédictible l'adresse de base du noyau (KASLR). L'entropie nécessaire doit être fournie par l'UEFI ou le chargeur de démarrage. `CONFIG_ARM64_SW_TTBR0_PAN=y` : Interdit les accès par le noyau à la mémoire utilisateur (équivalent à SMAP sur x86_64). `CONFIG_UNMAP_KERNEL_AT_EL0=y` : Contre-mesure à l'attaque Meltdown sur ARM (KPTI). Étapes pour architecture ARM64 : Configurer pour ARM64 : `make ARCH=arm64 menuconfig`. Activer les options dans "Kernel Features" et "Boot options". Compiler : `make ARCH=arm64 -j$(nproc)`. Installer le noyau ARM64. Note : Pour notre VM x86_64, ces options ne sont pas pertinentes. **Vérification** : Sur système ARM64 : `zcat /proc/config.gz | grep -E "(DEFAULT_MMAP_MIN_ADDR|RANDOMIZE_BASE|ARM64_SW_TTBR0_PAN|UNMAP_KERNEL_AT_EL0)"`. **Résultat** : État : Non applicable. Raison : Notre VM est en architecture x86_64, ces options sont spécifiques aux systèmes ARM64. **Commentaires** : Mesure non applicable à notre environnement. Ces protections sont importantes pour les serveurs et appareils mobiles modernes basés sur ARM64. La protection UNMAP_KERNEL_AT_EL0 est l'équivalent ARM de PTI pour contrer les attaques de type Meltdown. Les systèmes ARM64 deviennent de plus en plus courants dans les datacenters et l'edge computing. Impact sécurité : Élevé pour systèmes ARM64. ## R29 – Restreindre les accès au dossier /boot (p35) **Objectif** : Limiter l'accès au répertoire /boot qui contient des éléments sensibles du processus de démarrage (noyau, chargeur GRUB, fichiers de configuration). **Niveau ANSSI** : Intermédiaire **Principe associé** : Moindre privilège **Niveau Lynis** : Système de fichiers **Source** : ANSSI p.35 **Procédure** : Le répertoire /boot contient le noyau de démarrage et les fichiers System.map. Il ne doit pas être monté automatiquement au démarrage (option noauto) et l'accès doit être restreint. Étapes : Vérifier le point de montage actuel de /boot : `mount | grep /boot`. Modifier /etc/fstab pour ajouter l'option noauto : `UUID=[uuid-de-/boot] /boot ext4 defaults,noauto,nosuid,nodev,noexec 0 2`. Modifier les permissions du répertoire /boot : `chmod 700 /boot` (lecture/écriture/exécution pour root uniquement). Vérifier les permissions : `ls -ld /boot`. Pour les mises à jour du noyau, monter manuellement /boot : `mount /boot`. Après mise à jour, démonter : `umount /boot`. **Vérification** : Vérifier les permissions : `ls -ld /boot` doit afficher `drwx------` (700). Vérifier les options de montage : `mount | grep /boot` doit montrer les options nosuid,nodev,noexec,noauto. **Résultat** : État : Appliqué partiellement. Raison : Les permissions ont été restreintes à root (chmod 700), mais l'option noauto n'a pas été ajoutée car cela compliquerait les mises à jour automatiques. **Commentaires** : Mesure partiellement appliquée. La restriction d'accès à /boot est importante car ce répertoire contient des éléments critiques. L'option noauto augmente la sécurité mais rend les mises à jour plus complexes. Dans notre TP, nous conservons l'auto-montage pour la simplicité. Les options nosuid,nodev,noexec sont déjà appliquées via notre partitionnement (R28). Impact sécurité : Moyen à élevé selon l'exposition physique du système. ## R41 – Limiter les commandes nécessitant EXEC (p45) **Objectif** : Restreindre l'utilisation de la directive EXEC dans sudoers qui permet l'exécution de commandes avec élévation de privilèges, en particulier pour les commandes qui pourraient être détournées pour obtenir un shell complet. **Niveau ANSSI** : Renforcé **Principe associé** : Moindre privilège **Source** : ANSSI p.45 **Procédure** : 1. **Auditer les règles sudo existantes** : `sudo -l` pour voir les commandes autorisées à chaque utilisateur. 2. **Identifier les commandes dangereuses** qui pourraient donner un shell ou permettre une élévation de privilèges : éditeurs (vi, nano, vim), gestionnaires de fichiers, interpréteurs de commandes. 3. **Pour les commandes d'édition de fichiers**, utiliser `sudoedit` plutôt qu'un éditeur direct. Exemple : remplacer `ALL=(ALL) /usr/bin/vim` par `ALL=(ALL) sudoedit`. 4. **Restreindre les commandes avec des arguments précis** : `user ALL=(ALL) /usr/bin/apt update` plutôt que `user ALL=(ALL) /usr/bin/apt`. 5. **Utiliser NOEXEC** pour empêcher l'exécution de sous-processus : ajouter `NOEXEC:` devant la commande dans sudoers. **Vérification** : - Vérifier les règles sudo : `sudo -l`. - Tester les restrictions : essayer d'exécuter `sudo bash` ou `sudo vim` devrait être interdit. - Vérifier que sudoedit fonctionne correctement. **Résultat** : État : 🔶 Partiellement appliqué Raison : Configuration sudo basique avec restrictions sur les commandes autorisées, mais pas d'utilisation spécifique de NOEXEC. Notre utilisateur de test a des droits limités. Les éditeurs sont interdits via sudo, seul sudoedit est autorisé pour la modification de fichiers. **Commentaires** : Mesure importante pour empêcher le contournement des restrictions sudo. L'utilisation de NOEXEC est particulièrement efficace pour bloquer les tentatives d'obtention d'un shell. Dans notre TP, nous avons configuré sudo avec des commandes spécifiques plutôt qu'avec ALL, ce qui limite déjà les risques. La directive NOEXEC ajouterait une couche de sécurité supplémentaire mais nécessite une configuration plus fine. Impact sécurité : Élevé pour les systèmes avec plusieurs utilisateurs sudo. ## R45 – Activer et configurer des profils AppArmor (p48) **Objectif** : Activer le contrôle d'accès obligatoire (MAC) via AppArmor pour confiner les applications et services, limitant les dommages en cas de compromission. **Niveau ANSSI** : Renforcé **Principe associé** : Défense en profondeur **Source** : ANSSI p.48 **Procédure** : 1. **Vérifier l'état d'AppArmor** : `aa-status` pour voir les profils actifs. 2. **Installer AppArmor si nécessaire** : `apt install apparmor apparmor-utils`. 3. **Activer le service** : `systemctl enable apparmor` et `systemctl start apparmor`. 4. **Mettre les profils en mode "enforce"** (bloquant) plutôt que "complain" (journalisation seule) : `aa-enforce /etc/apparmor.d/*`. 5. **Profils à activer en priorité** : services réseau (sshd, nginx, apache), services système (cron, dbus), applications sensibles. 6. **Créer des profils personnalisés** si nécessaire avec `aa-genprof`. **Vérification** : - Vérifier le statut : `aa-status` doit montrer des profils en mode "enforce". - Vérifier le démarrage au boot : `systemctl is-enabled apparmor`. - Tester le confinement : essayer d'accéder à des fichiers non autorisés par un profil. **Résultat** : État : Appliqué Raison : AppArmor est installé et actif par défaut sur Debian. Plusieurs profils système sont en mode "enforce". Le service est activé au démarrage. Nous avons vérifié que les profils pour les services critiques (sshd, cron) sont actifs. **Commentaires** : Mesure conservée et appliquée. AppArmor fournit une couche de sécurité supplémentaire importante en limitant ce que chaque application peut faire, même si elle est compromise. La configuration par défaut de Debian est déjà bonne, avec de nombreux profils pré-installés. Pour un déploiement en production, il faudrait créer des profils pour les applications métier spécifiques. Impact sécurité : Élevé, réduit significativement la surface d'attaque des applications. ## R46 – Activer et configurer SELinux (p49) **Objectif** : Activer SELinux (Security-Enhanced Linux) comme mécanisme de contrôle d'accès obligatoire (MAC) alternatif à AppArmor, pour confiner les processus et renforcer la sécurité système. **Niveau ANSSI** : Renforcé **Principe associé** : Défense en profondeur **Source** : ANSSI p.49 **Procédure** : 1. **Vérifier si SELinux est disponible** : `sestatus` ou `getenforce`. 2. **Installer SELinux** : `apt install selinux-basics selinux-policy-default`. 3. **Configurer le mode** : éditer `/etc/selinux/config` pour définir `SELINUX=enforcing` et `SELINUXTYPE=default`. 4. **Activer SELinux** : `selinux-activate` puis redémarrer. 5. **Configurer la politique** : utiliser `semanage`, `setsebool`, `chcon` pour ajuster les règles. 6. **Vérifier les violations** : consulter `/var/log/audit/audit.log` et utiliser `ausearch` ou `sealert`. **Vérification** : - Vérifier l'état : `getenforce` doit retourner "Enforcing". - Vérifier la politique : `sestatus -v`. - Vérifier les logs d'audit pour les violations. **Résultat** : État : 🔶 Non appliqué Raison : Nous utilisons AppArmor comme mécanisme MAC principal, qui est la solution par défaut recommandée sur Debian. SELinux et AppArmor ne sont pas conçus pour fonctionner simultanément. Le choix d'AppArmor est cohérent avec les pratiques Debian/Ubuntu. **Commentaires** : Mesure écartée au profit d'AppArmor (R45). SELinux est plus puissant mais aussi plus complexe à configurer et maintenir. Son utilisation est plus courante sur les distributions Red Hat (RHEL, CentOS, Fedora). Dans notre contexte Debian, AppArmor offre un bon équilibre entre sécurité et facilité d'utilisation. Pour des environnements à haute sécurité nécessitant une granularité extrême, SELinux pourrait être considéré. Impact sécurité : Élevé (mais comparable à AppArmor bien configuré). ## R47 – Confiner les utilisateurs non privilégiés (p50) **Objectif** : Appliquer des restrictions aux utilisateurs non privilégiés pour limiter leurs actions sur le système, en utilisant des shells restreints, des profiles AppArmor, ou d'autres mécanismes de confinement. **Niveau ANSSI** : Renforcé **Principe associé** : Moindre privilège **Source** : ANSSI p.50 **Procédure** : 1. **Utiliser un shell restreint (rbash)** : `usermod -s /bin/rbash nom_utilisateur`. 2. **Créer un environnement restreint** : - Créer un répertoire `$HOME/bin` avec des liens symboliques vers les commandes autorisées - Définir un PATH limité : `PATH=$HOME/bin:/usr/bin` - Restreindre la modification des variables d'environnement 3. **Créer un profil AppArmor pour l'utilisateur** : `aa-genprof --username nom_utilisateur`. 4. **Utiliser chroot ou namespaces** pour isoler l'environnement utilisateur. 5. **Restreindre les commandes disponibles** via sudoers avec des règles spécifiques. **Vérification** : - Vérifier le shell de l'utilisateur : `grep ^nom_utilisateur /etc/passwd`. - Tester les restrictions : essayer d'exécuter `cd /`, `export PATH=...`, ou d'accéder à des fichiers systèmes. - Vérifier les profils AppArmor actifs pour l'utilisateur : `aa-status`. **Résultat** : État : 🔶 Partiellement appliqué Raison : Notre utilisateur de test a des droits limités mais n'utilise pas rbash. Le confinement principal se fait via les permissions UNIX standard et les restrictions sudo. Dans notre TP avec un seul utilisateur administrateur, cette mesure est moins critique. **Commentaires** : Mesure importante dans les environnements multi-utilisateurs ou avec des utilisateurs non techniques. Le shell restreint (rbash) empêche de changer de répertoire, de modifier les variables d'environnement, ou d'exécuter des commandes avec `/`. Pour un serveur avec plusieurs utilisateurs (ex: hébergement web), cette mesure serait essentielle. Dans notre TP mono-utilisateur administrateur, nous nous concentrons sur d'autres mesures de durcissement. Impact sécurité : Élevé pour les environnements multi-utilisateurs. ## R48 – Paramétrer les variables SELinux (p51) **Objectif** : Configurer les variables et politiques SELinux pour qu'elles correspondent aux besoins de sécurité de l'organisation, en ajustant les paramètres selon les services déployés et les contraintes opérationnelles. **Niveau ANSSI** : Renforcé **Principe associé** : Contrôle d'accès obligatoire **Source** : ANSSI p.51 **Procédure** : 1. **Afficher les paramètres SELinux actuels** : `sestatus -v`. 2. **Lister les variables booléennes** : `getsebool -a`. 3. **Modifier les variables booléennes** selon les besoins : - `setsebool -P httpd_can_network_connect on` (exemple pour Apache) - `setsebool -P ftp_home_dir off` (exemple pour FTP) 4. **Ajuster les contextes de fichiers** si nécessaire : `chcon -t httpd_sys_content_t /var/www/html`. 5. **Créer des politiques personnalisées** pour les applications métier : `audit2allow`. 6. **Vérifier et corriger les contextes** : `restorecon -Rv /chemin`. **Vérification** : - Vérifier les changements : `getsebool -a | grep httpd`. - Vérifier les contextes : `ls -Z /var/www/html`. - Vérifier les violations dans les logs : `grep AVC /var/log/audit/audit.log`. **Résultat** : État : 🔶 Non applicable Raison : Nous n'utilisons pas SELinux mais AppArmor comme mécanisme de contrôle d'accès obligatoire (R45). Les variables SELinux ne sont donc pas pertinentes dans notre configuration. **Commentaires** : Mesure non applicable dans notre environnement. SELinux et AppArmor sont deux solutions alternatives de MAC (Mandatory Access Control). Sur Debian, AppArmor est recommandé et pré-installé, tandis que SELinux serait plus adapté à un environnement Red Hat. Si SELinux était utilisé, cette mesure serait critique pour adapter la politique aux besoins spécifiques des services. L'ANSSI note que la politique par défaut (targeted) doit être ajustée pour chaque service exposé. Impact sécurité : Élevé (dans un environnement SELinux). ## R49 – Désinstaller les outils de debug SELinux (p52) **Objectif** : Retirer les outils de débogage et de développement SELinux des systèmes de production pour réduire la surface d'attaque et empêcher la collecte d'informations sur la politique de sécurité. **Niveau ANSSI** : Renforcé **Principe associé** : Minimisation **Source** : ANSSI p.52 **Procédure** : 1. **Identifier les paquets SELinux installés** : `dpkg -l | grep selinux`. 2. **Supprimer les outils de développement et débogage** : - `apt remove selinux-policy-dev setools-console` - `apt remove policycoreutils-dev libselinux1-dev` 3. **Conserver les composants essentiels** nécessaires au fonctionnement : - `selinux-basics` - `selinux-policy-default` - `policycoreutils` 4. **Vérifier les dépendances** avant désinstallation : `apt-cache rdepends nom_paquet`. 5. **Nettoyer les paquets inutilisés** : `apt autoremove --purge`. **Vérification** : - Vérifier les paquets restants : `dpkg -l | grep selinux`. - Tester la fonctionnalité SELinux de base : `sestatus` doit toujours fonctionner. - Vérifier que les outils de développement sont absents : `which audit2allow` (doit retourner vide). **Résultat** : État : 🔶 Non applicable Raison : Nous n'utilisons pas SELinux mais AppArmor (R45). Aucun outil SELinux n'est installé sur notre système Debian par défaut. **Commentaires** : Mesure non applicable dans notre configuration. Si SELinux était utilisé, cette recommandation serait importante car les outils de développement SELinux peuvent fournir des informations précieuses à un attaquant sur la politique de sécurité. Ils peuvent également contenir des vulnérabilités. En environnement de production, seuls les composants runtime essentiels doivent être conservés. Pour AppArmor, l'équivalent serait de désinstaller `apparmor-utils` si non nécessaires, mais nous les conservons pour la gestion des profils. Impact sécurité : Moyen (réduction surface d'attaque). ## R51 – Changer les secrets et les droits d'accès dès l'installation (p53) **Objectif** : Modifier immédiatement après l'installation tous les secrets (mots de passe, clés cryptographiques) et vérifier les droits d'accès par défaut pour s'assurer qu'ils correspondent à la politique de sécurité de l'organisation. **Niveau ANSSI** : Intermédiaire **Principe associé** : Sécurité par défaut **Source** : ANSSI p.53 **Procédure** : Changer tous les mots de passe par défaut : `passwd root`. Regénérer les clés SSH de l'hôte : `rm /etc/ssh/ssh_host_*` puis `dpkg-reconfigure openssh-server`. Vérifier et corriger les permissions par défaut : `/etc/shadow` en `chmod 640` et `chown root:shadow`, `/etc/passwd` en `chmod 644`, `/etc/group` en `chmod 644`. Regénérer les secrets des services : clés SSL/TLS si présentes, tokens d'authentification. Supprimer les fichiers d'installation temporaires contenant des informations sensibles. **Vérification** : Vérifier les permissions des fichiers sensibles : `ls -l /etc/shadow /etc/passwd`. Vérifier la date de création des clés SSH : `ls -l /etc/ssh/ssh_host_*`. Tester que les nouveaux mots de passe fonctionnent. **Résultat** : État : Appliqué. Raison : Dès l'installation de notre VM Debian, nous avons défini des mots de passe robustes (R31). Les clés SSH de l'hôte ont été générées lors de l'installation. Les permissions des fichiers sensibles ont été vérifiées et sont conformes aux standards Debian. Aucun service applicatif avec secrets par défaut n'a été installé. **Commentaires** : Mesure conservée et appliquée. Cette pratique est essentielle pour éviter les attaques utilisant les informations par défaut (credentials factory, clés SSH connues). Dans notre installation minimale, peu de secrets étaient présents, mais nous avons tout de même vérifié les éléments critiques. Pour des installations plus complexes, il faudrait également changer les mots de passe des bases de données, tokens d'API, etc. Impact sécurité : Élevé, prévient les attaques basées sur les configurations par défaut. ## R57 – Éviter les exécutables setuid root (p55) **Objectif** : Minimiser le nombre d'exécutables avec le bit setuid activé et appartenant à root, car ils représentent un risque élevé d'élévation de privilèges en cas de vulnérabilité. **Niveau ANSSI** : Intermédiaire **Principe associé** : Minimisation **Source** : ANSSI p.55 **Procédure** : Identifier tous les exécutables setuid root : `find / -type f -perm -4000 -user root 2>/dev/null`. Analyser chaque exécutable pour déterminer s'il est essentiel au fonctionnement du système. Pour les exécutables non essentiels, retirer le bit setuid : `chmod u-s /chemin/vers/exécutable`. Rechercher des alternatives plus sécurisées, par exemple utiliser `sudo` plutôt qu'un exécutable setuid. Vérifier régulièrement après les mises à jour que de nouveaux exécutables setuid root n'ont pas été ajoutés. **Vérification** : Vérifier la liste réduite des exécutables setuid root : `find / -type f -perm -4000 -user root 2>/dev/null | wc -l`. Tester que les fonctionnalités essentielles fonctionnent toujours (ex: `passwd`, `su`). Vérifier que les exécutables non essentiels n'ont plus le bit setuid. **Résultat** : État : Appliqué. Raison : Nous avons audité les exécutables setuid root après l'installation minimale. Seuls les exécutables essentiels ont été conservés (`passwd`, `su`, `mount`, `umount`, etc.). Aucun exécutable applicatif non essentiel avec setuid root n'était présent. Nous avons également supprimé le bit setuid sur certains exécutables comme `crontab` qui n'étaient pas nécessaires dans notre configuration. **Commentaires** : Mesure conservée et appliquée. La réduction des exécutables setuid root est cruciale car chaque programme avec ces privilèges représente un vecteur d'attaque potentiel. Dans notre VM minimale, la liste était déjà restreinte. Pour des systèmes plus complexes, il faudrait auditer soigneusement chaque exécutable. L'utilisation de mécanismes comme `sudo` ou `capabilities` peut parfois remplacer avantageusement les bits setuid. Impact sécurité : Élevé, réduit significativement les vecteurs d'élévation de privilèges. ## R60 – Utiliser des dépôts durcis (p57) **Objectif** : Utiliser des dépôts de paquets qui ont subi un durcissement spécifique ou qui proviennent d'une source certifiée, offrant ainsi un niveau de sécurité supérieur aux dépôts standards. **Niveau ANSSI** : Intermédiaire **Principe associé** : Chaîne d'approvisionnement sécurisée **Source** : ANSSI p.57 **Procédure** : Identifier les dépôts Debian disponibles avec des paquets durcis. En général, utiliser les dépôts Debian standard qui intègrent déjà certaines mesures de sécurité. Pour des besoins spécifiques, évaluer l'utilisation de dépôts supplémentaires comme `debian-security` ou `debian-hardened`. Vérifier la signature GPG des dépôts configurés dans `/etc/apt/sources.list` et `/etc/apt/sources.list.d/`. Éviter les dépôts tiers non officiels. Configurer apt pour n'utiliser que des paquets signés : dans `/etc/apt/apt.conf.d/`, ajouter `APT::Get::AllowUnauthenticated "false";`. **Vérification** : Vérifier les dépôts configurés : `cat /etc/apt/sources.list`. Vérifier que les signatures sont activées : `grep -r AllowUnauthenticated /etc/apt/apt.conf.d/`. Tenter une mise à jour avec un dépôt non signé devrait échouer. Vérifier la validité des clés GPG : `apt-key list`. **Résultat** : État : Appliqué. Raison : Nous utilisons exclusivement les dépôts Debian officiels qui sont signés et maintenus par l'équipe de sécurité Debian. La configuration par défaut de Debian n'autorise pas l'installation de paquets non signés. Nous avons vérifié que seuls les dépôts Debian standards (main, security) sont configurés. **Commentaires** : Mesure conservée et appliquée. Les dépôts Debian officiels offrent un bon niveau de sécurité avec des paquets signés et des mises à jour de sécurité rapides. Bien que Debian ne propose pas de dépôts spécifiquement "durcis" comme certaines autres distributions, sa politique de sécurité rigoureuse et sa grande communauté de développeurs assurent une qualité suffisante pour la plupart des cas d'usage. Pour des environnements à très haute sécurité, on pourrait envisager des distributions comme Alpine Linux ou des compilations maison avec des options de durcissement. Impact sécurité : Élevé, garantit l'intégrité des paquets installés. ## R64 – Configurer les privilèges des services (p59) **Objectif** : Limiter les privilèges des services système au strict nécessaire en utilisant les fonctionnalités de contrôle d'accès (capabilities Linux, sandboxing) pour réduire l'impact d'une compromission. **Niveau ANSSI** : Renforcé **Principe associé** : Moindre privilège **Source** : ANSSI p.59 **Procédure** : Pour chaque service systemd, définir des restrictions dans le fichier de service (`.service`) : `CapabilityBoundingSet=` pour limiter les capabilities Linux, `ReadWritePaths=` et `ReadOnlyPaths=` pour contrôler l'accès aux fichiers, `PrivateTmp=yes` pour isoler le répertoire temporaire, `NoNewPrivileges=yes` pour empêcher l'escalade de privilèges, `ProtectSystem=strict` pour protéger les répertoires système. Exemple pour un service web : `CapabilityBoundingSet=CAP_NET_BIND_SERVICE`. Utiliser `systemd-analyze security nom_du_service` pour évaluer la sécurité d'un service. Appliquer les modifications via `systemctl edit nom_du_service`. **Vérification** : Vérifier la configuration d'un service : `systemctl show nom_du_service | grep -E "(Capability|Private|Protect|NoNewPrivileges)"`. Tester que le service fonctionne toujours avec les restrictions. Vérifier qu'aucun service n'a des privilèges excessifs : `systemd-analyze security` pour tous les services. **Résultat** : État : 🔶 Partiellement appliqué. Raison : Nous avons appliqué des restrictions de base aux services comme SSH avec `PrivateTmp=yes`, mais n'avons pas configuré toutes les options de sandboxing systemd pour tous les services. Notre installation minimale avec peu de services limite l'impact de cette mesure. Les services système essentiels ont conservé leurs privilèges par défaut pour assurer la stabilité. **Commentaires** : Mesure importante pour limiter l'impact d'une compromission de service. Systemd offre de nombreuses options de sandboxing souvent sous-utilisées. Dans notre TP, nous pourrions durcir davantage le service SSH. Pour un déploiement en production avec plusieurs services, cette mesure serait prioritaire. Attention : trop de restrictions peuvent rendre un service inopérant, nécessitant des tests approfondis. Impact sécurité : Élevé pour les services exposés au réseau. ## R65 – Cloisonner les services (p60) **Objectif** : Isoler les services entre eux et du reste du système en utilisant des mécanismes de cloisonnement pour limiter la propagation d'une compromission. **Niveau ANSSI** : Renforcé **Principe associé** : Isolement **Source** : ANSSI p.60 **Procédure** : Utiliser les fonctionnalités de namespaces de systemd pour chaque service : `PrivateDevices=yes` pour isoler l'accès aux périphériques, `PrivateNetwork=yes` pour les services n'ayant pas besoin de réseau (sinon `PrivateNetwork=no` avec filtrage), `PrivateUsers=yes` pour créer un namespace utilisateur séparé, `ProtectHome=yes` pour empêcher l'accès aux répertoires utilisateurs, `ProtectSystem=strict` pour protéger les répertoires système. Créer des unités de service dédiées pour chaque fonctionnalité plutôt que d'avoir des services monolithiques. Utiliser des conteneurs (Docker, LXC) ou des machines virtuelles pour une isolation plus forte des services complexes. **Vérification** : Vérifier les paramètres de cloisonnement : `systemctl show nom_du_service | grep -i private`. Tester l'isolation : vérifier qu'un service cloisonné ne peut pas voir les processus des autres services (`ps aux` depuis le contexte du service). Vérifier que les fonctionnalités réseau restent opérationnelles si nécessaire. **Résultat** : État : 🔶 Partiellement appliqué. Raison : Nous avons appliqué un cloisonnement de base au service SSH avec quelques options de sandboxing systemd, mais n'avons pas poussé l'isolation à son maximum. Notre installation minimale avec peu de services réduit le besoin de cloisonnement avancé. Les services critiques comme systemd-logind ont conservé leurs privilèges pour la stabilité du système. **Commentaires** : Mesure importante pour les environnements multi-services. Le cloisonnement empêche un service compromis d'attaquer d'autres services ou le système hôte. Dans une architecture microservices ou avec plusieurs applications, cette mesure serait critique. Les conteneurs offrent une isolation plus forte mais ajoutent de la complexité. Pour notre TP mono-service (SSH), le cloisonnement a une utilité limitée mais reste une bonne pratique. Impact sécurité : Élevé pour les environnements avec plusieurs services.

Syntax	Example	Reference
# Header	Header	基本排版
- Unordered List	Unordered List
1. Ordered List	Ordered List
- [ ] Todo List	Todo List
> Blockquote	Blockquote
Bold font	Bold font
Italics font	Italics font
~~Strikethrough~~	~~Strikethrough~~
19^th^	19^th
H~2~O	H₂O
++Inserted text++	Inserted text
==Marked text==	Marked text
[link text](https:// "title")	Link
![image alt](https:// "title")	Image
`Code`	`Code`	在筆記中貼入程式碼
```javascript var i = 0; ```	`var i = 0;`
:smile:		Emoji list
{%youtube youtube_id %}	Externals
$L^aT_eX$	L^aT_eX
:::info This is a alert area. :::	This is a alert area.