### Mesure R55 — Séparer les répertoires temporaires des utilisateurs *Source :* ANSSI – Recommandation R55 [https://www.ssi.gouv.fr/guide/linux/](https://www.ssi.gouv.fr/guide/linux/) ##### Objectif Limiter les risques d’escalade de privilèges via `/tmp`, qui est un espace partagé entre utilisateurs. ##### Contexte Sur notre installation, seuls des administrateurs accèdent au serveur via SSH et l’environnement est minimal. Le risque est **faible**, mais la séparation peut être appliquée si un cloisonnement supplémentaire est souhaité. ##### Mesure proposée (optionnelle) Activer `pam_namespace` afin d’isoler `/tmp` par utilisateur. ```bash sudo apt install libpam-modules ``` Dans `/etc/security/namespace.conf` : ```text /tmp /tmp-inst/ level root,adm ``` Dans `/etc/pam.d/sshd` : ```text session required pam_namespace.so ``` --- ### Mesures R56 & R57 — Éviter les exécutables setuid / setgid *Source :* ANSSI R56, R57 [https://www.ssi.gouv.fr/guide/linux/](https://www.ssi.gouv.fr/guide/linux/) ##### Objectif Réduire les risques associés aux programmes pouvant s’exécuter avec des privilèges élevés. ##### Ce que nous avons fait Nous avons recensé les binaires setuid/setgid et conservé seulement ceux qui sont indispensables au fonctionnement normal de Debian (ex. `sudo`, `ping`). Tous ceux non nécessaires doivent être désactivés. ##### Étapes pour l’administrateur Lister les binaires : ```bash sudo find / -type f -perm /6000 -ls ``` Pour désactiver un binaire inutile : ```bash sudo chmod u-s /chemin/binaire sudo chmod g-s /chemin/binaire ``` ##### Pourquoi cette recommandation est importante ? Les setuid root sont une cible classique d'exploitation. Même si notre système est minimal, le vérifier reste essentiel. L’analyse des binaires setuid/setgid révèle uniquement les exécutables standards fournis par Debian dans un environnement minimal : sudo, passwd, ping, mount, umount, newgrp, chfn, chsh, ssh-keysign, su. Aucun binaire tiers ou anormal n’a été identifié. --- ### Mesure R58 — Installer uniquement les paquets nécessaires ##### Objectif Réduire la surface d’attaque en limitant les logiciels présents sur le serveur. ##### Ce que nous avons fait Le serveur a été installé en **version minimale** : * Aucune interface graphique * Aucun service réseau inutile * Uniquement `openssh-server` + outils de base ```bash apt-mark showmanual ``` --- ### Mesure R59 — Utiliser des dépôts de paquets de confiance *Source Debian* [https://wiki.debian.org/SourcesList](https://wiki.debian.org/SourcesList) ##### Objectif Éviter des dépôts non officiels ou compromis. ##### Ce que nous avons fait La configuration `/etc/apt/sources.list` contient **uniquement les dépôts Debian officiels**. ##### Pour vérifier ```bash grep -R "deb " /etc/apt/sources.list* ``` --- ### Mesure R60 — Utiliser des dépôts de paquets durcis ##### Objectif S’assurer que les paquets proviennent de dépôts maintenus et corrigés. ##### Notre cas Debian stable + dépôts de sécurité correspondent exactement à cette recommandation. On est déjà conforme. --- ### Mesure R61 — Effectuer des mises à jour régulières *Documentation officielle "unattended-upgrades"* [https://wiki.debian.org/UnattendedUpgrades](https://wiki.debian.org/UnattendedUpgrades) ##### Objectif Assurer l’application automatique des correctifs de sécurité. ##### Ce que nous avons mis en place Installation et activation de `unattended-upgrades` : ```bash sudo apt install unattended-upgrades sudo dpkg-reconfigure unattended-upgrades ``` --- ### Mesure R62 — Désactiver les services non nécessaires ##### Objectif Réduire la surface d’attaque. ##### Ce que nous avons fait Seul **SSH** écoute sur le réseau. ##### Vérification : ```bash sudo ss -tulpen ``` --- ### Mesure R63 — Désactiver les fonctionnalités non essentielles d’un service ##### Objectif Limiter SSH aux fonctionnalités minimales. ##### Ce que nous avons appliqué dans `/etc/ssh/sshd_config` ```ini PermitRootLogin no PasswordAuthentication no ChallengeResponseAuthentication no X11Forwarding no AllowTcpForwarding no AllowAgentForwarding no ``` *OpenSSH hardening:* [https://www.ssh-audit.com/hardening_guides.html](https://www.ssh-audit.com/hardening_guides.html) --- ### Mesure R64 — Configurer les privilèges des services ##### Objectif S'assurer que les services tournent sous des comptes dédiés. ##### Dans notre cas OpenSSH utilise déjà un utilisateur dédié (`sshd`). Aucune action requise. --- ### Mesure R65 — Cloisonner les services ##### Objectif Limiter l’impact d’un service compromis. ##### Pourquoi nous ne l’appliquons pas ici Le serveur n’exécute **qu’un seul service** : SSH. Le cloisonnement avancé (chroot, containers, SELinux…) n'apporte **pas de bénéfice significatif** dans notre environnement. La recommendation n'est pas pertinente ici. --- ### Mesure R66 — Durcir les composants de cloisonnement Même logique que R65 → Non pertinent pour une machine mono-service. Debian utilise déjà **AppArmor**, suffisant pour SSH. --- ### Mesure R67 — Sécuriser l’authentification distante via PAM ##### Objectif Limiter les tentatives abusives. ##### Ce que nous avons mis en place Désactivation des mots de passe → **authentification par clés SSH uniquement**. Ajout d’une protection PAM (`pam_faillock`) : ```text auth required pam_faillock.so preauth silent audit deny=5 unlock_time=600 ``` Documentation : [https://manpages.debian.org/pam_faillock](https://manpages.debian.org/pam_faillock) --- ### Mesure R68 — Protéger les mots de passe stockés ##### Objectif S’assurer que les hachages des mots de passe sont robustes. ##### Mise en conformité Nous utilisons l’algorithme **yescrypt**, recommandé depuis Debian 12. Dans `/etc/pam.d/common-password` : ```text password required pam_unix.so obscure yescrypt ``` *Debian Password Hashing:* [https://wiki.debian.org/PasswordHashing](https://wiki.debian.org/PasswordHashing) --- ### Mesure R69 — Sécuriser les accès aux bases utilisateur distantes ##### Pourquoi non appliqué Le système n’utilise **aucun annuaire LDAP/NIS** → uniquement `/etc/passwd`. La recommandation est inutile sur ce cas. --- ### Mesure R70 — Séparer les comptes système et d’administration de l’annuaire Même justification : Non applicable sans annuaire distant. --- ### Mesure R71 — Mettre en place un système de journalisation ##### Objectif Assurer une conservation durable des logs. ##### Ce que nous avons configuré Dans `/etc/systemd/journald.conf` : ```ini Storage=persistent SystemMaxUse=500M ``` journalctl documentation : [https://www.freedesktop.org/software/systemd/man/journalctl.html](https://www.freedesktop.org/software/systemd/man/journalctl.html) --- ### Mesure R72 — Journaux d’activité des services dédiés ##### Objectif Faciliter l’analyse des incidents. ##### Notre choix Utiliser journald (suffisant sur machine mono-service). --- ### Mesure R73 — Journaliser l’activité système avec auditd ##### Objectif Surveiller les accès sensibles (modules noyau, fichiers critiques…). ##### Mise en place Installation : ```bash sudo apt install auditd ``` Activation de règles : ```text -w /etc/ -p wa -w /sbin/insmod -p x -w /bin/kmod -p x ``` Documentation : [https://linux.die.net/man/8/auditd](https://linux.die.net/man/8/auditd) --- ### Mesure R74 — Durcir la messagerie locale ##### Non applicable Aucun MTA n’est installé (ni Postfix, ni Exim). Le service de messagerie locale n’existe pas, rien à configurer. --- ### Mesure R75 — Configurer les alias de messagerie des comptes de service Même raison : Non applicable. --- ### Mesures R76 & R77 — Scellement et protection de l’intégrité ##### Objectif Détecter toute modification anormale du système. ##### Mise en place d'AIDE ```bash sudo apt install aide sudo aideinit sudo cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db ``` Planification hebdomadaire : ```cron 0 3 * * 1 /usr/bin/aide --check ``` Documentation : [https://aide.github.io/](https://aide.github.io/) --- ### Mesure R78 — Cloisonner les services réseau ##### Déjà pris en compte Le serveur ne fournit **qu’un seul service** → cloisonnement naturel. --- ### Mesure R79 — Durcir et surveiller les services exposés ##### Objectif Protéger le seul service exposé : SSH. ##### Mise en place * Durcissement du fichier `sshd_config` * Surveillance avec `journalctl` * (Optionnel) Installation de fail2ban ```bash sudo apt install fail2ban ``` Fail2ban : [https://www.fail2ban.org/](https://www.fail2ban.org/) --- ### Mesure R80 — Réduire la surface d’attaque réseau ##### Objectif Limiter l’écoute réseau du service. ##### Ce que nous avons fait Dans `/etc/ssh/sshd_config` : ```ini AddressFamily inet ListenAddress 0.0.0.0 ``` Activation du firewall minimal (UFW) : ```bash sudo apt install ufw sudo ufw default deny incoming sudo ufw allow 22/tcp sudo ufw enable ``` ## Recommandations ANSSI – Authentification multifacteur & mots de passe ### Mesure R1 — Privilégier l’authentification multifacteur (MFA) *Source : ANSSI — R1* [https://cyber.gouv.fr/](https://cyber.gouv.fr/publications/recommandations-relatives-lauthentification-multifacteur-et-aux-mots-de-passe) #### Objectif Combiner **plusieurs facteurs** (connaissance, possession, inhérent). Attention : deux mots de passe = pas du MFA. #### Application sur la VM Même si la VM n’est pas un service à utilisateurs multiples, l'accès admin repose sur : * **Facteur de possession** : la clé privée SSH détenue physiquement par l’administrateur. * **Facteur de connaissance** : la passphrase qui protège cette clé. **Cela correspond déjà à deux facteurs**, sans mécanisme supplémentaire côté VM. #### Pourquoi c’est suffisant * La VM n’a qu’un usage d’administration interne. * Aucun service public ni multi-utilisateur. * Les recommandations MFA complètes (OTP, FIDO2…) seraient disproportionnées. --- ### Mesure R2 — Utiliser des moyens d’authentification forts #### Objectif Favoriser des mécanismes cryptographiques robustes (FIDO2, certificats, clés asymétriques…). #### Application sur la VM * Utilisation d’une **clé SSH Ed25519**, recommandée par OpenSSH. * Algorithmes modernes, robustes, résistants au quantique à court terme. #### Conclusion Aucune action complémentaire n’est nécessaire : l’usage exclusif des **clés SSH** satisfait pleinement la recommandation. --- ### Mesure R3 — Réaliser une analyse de risque adaptée #### Ce que nous avons fait Analyse simple adaptée au périmètre VM : * **Faible surface d’attaque** : seul SSH est ouvert. * **Impact fort** si compromis : accès root + pivot potentiel. * **Mesures de mitigation** : SSH à clés, firewall, journaux persistants, AIDE. L’environnement VM justifie un durcissement raisonnable, sans excès de mécanismes MFA. --- ### Mesure R4 — Générer les facteurs dans un environnement maîtrisé #### Application Les clés SSH sont générées **uniquement** sur le poste de l’administrateur : ```bash ssh-keygen -t ed25519 ``` Cet environnement local est considéré comme maîtrisé. Aucun facteur n’est généré sur la VM elle-même. --- ### Mesure R5 — Utiliser un générateur d’aléa robuste #### Application `ssh-keygen` s’appuie sur `/dev/urandom`, générateur d’aléa cryptographiquement sûr de Linux. La VM Debian garantit déjà un RNG fiable. --- ### Mesure R6 — Remettre les facteurs via des canaux sécurisés #### Application Aucun mot de passe ou secret n’est transmis à un utilisateur. La **clé publique** SSH est simplement copiée dans `authorized_keys`. Elle n’est **pas un secret**, donc aucun canal sécurisé spécifique n'est requis. La recommandation est **naturellement satisfaite**. --- ### Mesure R7 — Prévoir un renouvellement des facteurs #### Application Nous définissons une politique simple : * Renouvellement des clés SSH **tous les 2–3 ans** * ou immédiatement en cas de doute (perte du PC, malware, départ d’un administrateur). Procédure documentée : 1. Générer nouvelle clé 2. Ajouter la clé publique 3. Tester 4. Supprimer l’ancienne clé --- ### Mesure R8 — Ne jamais utiliser le SMS comme second facteur #### Application Aucun mécanisme SMS n’est utilisé. Recommandation **non applicable** mais respectée. --- ### Mesure R9 — Conserver l’historique des authentifications #### Application sur la VM Les logs SSH sont stockés dans : ``` /var/log/auth.log ``` Nous avons activé la **journalisation persistante** via journald, ce qui respecte la recommandation. --- ### Mesure R10 — Limiter les tentatives d’authentification #### Application Bien que les mots de passe soient désactivés, nous avons ajouté **Fail2ban** pour bloquer les IP trop insistantes : ```bash sudo apt install fail2ban ``` Cela renforce la VM face aux scans automatisés. --- ### Mesure R11 — Authentification via un canal sécurisé #### Application SSH chiffre nativement toutes les communications. Aucun autre protocole n’est exposé. La recommandation est **pleinement respectée**. --- ### Mesure R12 — Limiter la durée des sessions #### Application Dans `/etc/ssh/sshd_config` : ``` ClientAliveInterval 300 ClientAliveCountMax 1 ``` Après 5 minutes d’inactivité, la session est fermée. --- ### Mesure R13 — Protéger les données d’authentification stockées #### Application * Les mots de passe Linux sont hachés via **yescrypt**, stockés dans `/etc/shadow`. * Les clés privées SSH **ne sont pas sur la VM**, seulement les clés publiques. Aucune action supplémentaire requise. --- ### Mesure R14 — Ne pas préciser quel facteur échoue #### Application SSH renvoie un message générique `Permission denied`. Complètement conforme à la recommandation. --- ### Mesure R15 — Définir un délai d’expiration des facteurs #### Application adaptative * Pas d’expiration automatique des mots de passe Linux (bonne pratique ANSSI → éviter les rotations fréquentes). * Expiration **manuelle** des clés SSH en cas d'incident ou de révision. Approche cohérente avec une VM mono-admin. --- ### Mesure R16 — Définir des règles d’usage des facteurs #### Politique appliquée * Chaque administrateur possède **sa propre clé SSH**. * La clé privée reste **uniquement** sur son poste, chiffrée par passphrase. * Révocation immédiate en cas de départ ou d’incident. --- ### Mesure R17 — Sensibiliser les utilisateurs #### Application Les administrateurs sont informés des bonnes pratiques : * protection de la clé privée, * interdiction de transfert par mail, * poste de travail sécurisé. --- ### Mesures R18 & R19 — Révocation des facteurs compromettus #### Application En cas de suspicion : 1. Suppression immédiate dans `authorized_keys` 2. Vérification des logs 3. Rotation du mot de passe root si nécessaire Révocation immédiate → recommandation pleinement respectée. --- ### Mesure R20 — Définir une politique de mots de passe #### Application Comme l'accès SSH par mot de passe est désactivé, la politique porte uniquement sur : * les **mots de passe locaux** (root, admin), * la **passphrase de la clé SSH**. Politique adoptée : * longueur ≥ 15 caractères, * phrase de passe recommandée, * stockage dans un **coffre-fort**. --- ### Mesure R21 — Longueur minimale #### Application Pour les mots de passe locaux : **≥ 15 caractères**, idéalement phrase de passe. --- ### Mesure R22 — Ne pas imposer de plafond de longueur #### Application Aucune limite maximale n'est imposée côté PAM → conforme. --- ### Mesure R23 — Complexité minimale #### Application Recommandé mais pas forcé par PAM, car l’usage est restreint à l’administration. Documenté : * majuscules, minuscules, chiffres, symboles, * ou phrase mémoire robuste. --- ### Mesures R24 & R25 — Expiration des mots de passe #### Application Conforme aux bonnes pratiques ANSSI : * **pas d’expiration automatique**, * **rotation obligatoire en cas de suspicion** ou changement d’administrateur. --- ### Mesure R26 — Révocation immédiate des mots de passe compromis #### Application Réinitialisation immédiate avec : ```bash passwd root ``` --- ### Mesure R27 — Contrôler la robustesse lors de la création #### Application Pas de mécanisme automatique (inutile dans une VM mono-admin). Cette exigence est intégrée dans la documentation : mot de passe long, non trivial. --- ### Mesure R28 — Utiliser un sel aléatoire long #### Application Debian utilise automatiquement un sel unique dans `/etc/shadow`. Recommandation **déjà satisfaite**. --- ### Mesure R29 — Utiliser une fonction de dérivation robuste #### Application Debian 12 utilise **yescrypt**, recommandé par l’ANSSI. Aucune modification nécessaire. --- ### Mesure R30 — Méthode de recouvrement d’accès #### Application Sur une VM, le recouvrement se fait via : * accès console / hyperviseur, * réinitialisation avec `passwd`, * remplacement d’une clé SSH. Pas de service d’auto-récupération (non pertinent). --- ### Mesure R31 — Utiliser un coffre-fort de mots de passe #### Application L’administrateur utilise un gestionnaire de mots de passe externe (Bitwarden, KeePass…). La VM n’héberge pas de coffre-fort → hors périmètre. --- ### Mesure R32 — Utiliser des mots de passe robustes #### Objectif Garantir que les mots de passe utilisés ne puissent pas être devinés ou bruteforcés facilement. #### Application dans notre cas Les seuls secrets utilisés sont : * la passphrase de la clé SSH, * le mot de passe root. Ces mots de passe sont **longs**, **robustes** et construits selon les bonnes pratiques recommandées (phrase de passe ou combinaison riche). --- ### Mesure R33 — Utiliser un mot de passe différent par service #### Objectif Limiter l’impact d’une compromission éventuelle. #### Application dans notre cas Les secrets liés à la VM sont **tous distincts** : * la passphrase SSH n’est utilisée nulle part ailleurs, * le mot de passe root n’est pas partagé avec d’autres systèmes. Aucun secret utilisé sur la VM n’est réutilisé hors de cet environnement. --- ### Mesure R34 — Utiliser un coffre-fort de mots de passe #### Objectif Encourager les utilisateurs à stocker leurs mots de passe dans un outil sécurisé plutôt que dans des fichiers ou notes. #### Application dans notre cas Cette recommandation s’adresse à des utilisateurs finaux d’un service. La VM n’en héberge aucun : * un seul administrateur, * pas d’interface web, * pas de comptes utilisateur à gérer. La recommandation est donc hors périmètre --- ### Mesure R35 — Protéger ses mots de passe #### Objectif Éviter toute fuite ou exposition des secrets. #### Application dans notre cas Les mots de passe : * ne sont jamais copiés dans des fichiers non chiffrés, * ne sont jamais envoyés par message ou stockage en ligne, * ne sont jamais partagés, * sont strictement utilisés pour cette VM. --- ### Mesure R36 — Utiliser un mot de passe robuste pour les services sensibles #### Objectif Assurer un niveau de sécurité renforcé pour les comptes administrateur. #### Application dans notre cas Le **mot de passe root** (seul compte sensible local) est robuste, long et unique. Même si l’authentification SSH utilise les clés, le mot de passe root reste un élément critique et suit les exigences ANSSI. --- ### Mesure R37 — Ne pas utiliser d’informations personnelles #### Objectif Éviter les mots de passe fondés sur des éléments personnels prévisibles. #### Application dans notre cas Les mots de passe utilisés pour la VM : * ne contiennent aucune information personnelle (nom, dates, pseudonymes…), * sont générés selon des critères de robustesse, * sont stockés seulement dans le coffre-fort. --- ### Mesure R38 — Modifier les mots de passe par défaut #### Objectif Supprimer tout secret fourni d’origine par un système ou un équipement. #### Application dans notre cas La VM Debian ne contient aucun mot de passe par défaut à l’installation. Tous les mots de passe créés (notamment root) ont été définis manuellement dès la configuration initiale. --- ### Mesure R39 — Utiliser un facteur de possession avec composant de sécurité qualifié ### Mesure R39- — Utiliser un facteur de possession avec composant de sécurité ### Mesure R39-- — Utiliser un facteur de possession même sans composant matériel #### Objectif Garantir que le facteur de possession est difficile à copier et bien protégé. #### Application dans notre cas Le **facteur de possession est la clé SSH privée** utilisée pour accéder à la VM. Elle est : * stockée localement sur ton poste, * protégée par une **passphrase robuste**, * sécurisée dans ton coffre-fort, * jamais transférée sur la VM. Nous sommes donc dans le cas **R39--** (facteur logiciel protégé), ce qui est cohérent. --- ### R40 — Ne pas utiliser un facteur inhérent seul ### R41 — Associer le facteur inhérent à un facteur fort ### R42 — Enrôler le facteur inhérent en présence ### Pourquoi ce n’est pas applicable * Une **VM Debian en ligne de commande** ne supporte aucune forme de biométrie. * SSH ne propose **aucun mécanisme biométrique serveur**. * Il n’y a **pas d’utilisateur final**, seulement un administrateur technique. * Aucun capteur biométrique ni processus d’enrôlement n’existe dans cet environnement.