---
# System prepended metadata

title: "\U0001F6E1️ Durcissement ANSSI – Recommandations R55 à R80"

---

### 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.







