# Sécurisation Linux

Ce wiki a pour objectif de présenter les bonnes pratiques de sécurisation d’un système Linux mises en place par notre groupe, en s’appuyant sur les recommandations officielles de l’ANSSI :
- [Recommandations de sécurité relatives à un système GNU/Linux](https://cyber.gouv.fr/publications/recommandations-de-securite-relatives-un-systeme-gnulinux)
- [Usage sécurisé d’(Open)SSH](https://cyber.gouv.fr/publications/usage-securise-dopenssh)
- [Recommandations relatives à l'authentification multifacteur et aux mots de passe](https://cyber.gouv.fr/publications/recommandations-relatives-lauthentification-multifacteur-et-aux-mots-de-passe)
---
### Sommaire
[toc]

---

## Nos audits de sécurité avec Lynis

Afin d’évaluer l’impact progressif des mesures de durcissement mises en œuvre, plusieurs audits de sécurité ont été réalisés à l’aide de l’outil Lynis, donnant lieu à différents comptes rendus. Un premier audit initial `initial_report.html` a été effectué avant toute configuration de sécurité, avec un score global de 64, servant de référence. Par la suite, l’application partielle des mesures R1 à R14 du référentiel Linux (niveau M et MI uniquement) a permis d’obtenir un second rapport `de_R1_a_R14_uniquement_M_ou_MI.html` avec un score de 66. Un troisième audit, centré sur le durcissement du service SSH conformément au référentiel OpenSSH `referentiel_openssh.html`, a mis en évidence une amélioration supplémentaire, portant le score à 68. Enfin, l’application partielle des mesures R55 à R80 du référentiel (toujours limitées aux niveaux M et MI) a conduit à un dernier rapport `de_R55_a_R80_uniquement_M_ou_MI.html` avec un score de 73. Il est important de préciser que ces résultats reflètent une mise en œuvre progressive et partielle des recommandations : certaines mesures n’ont pas été appliquées, soit parce qu’elles étaient hors périmètre, soit parce qu’elles nécessitaient des contraintes matérielles, organisationnelles ou fonctionnelles non compatibles avec le contexte du système étudié.

## Mesures relatives aux recommandations de sécurité relatives à un système GNU/Linux

Chaque recommandation de ce référentiel est classée selon la nécessité plus ou moins importante de cette recommandation à être mise en place.

---

### Mesure R2 - Configurer le BIOS / UEFI

:::danger
Recommendation de niveau intermédiaire (MI)
:::

La configuration du BIOS/UEFI doit être vérifiée avant l’installation pour garantir que seules les fonctionnalités nécessaires sont activées. Désactiver les options inutiles, bloquer le boot externe et activer les protections matérielles permet de réduire les risques de compromission dès le démarrage. Ces réglages se font directement en GUI dans l’interface BIOS / UEFI.

### Mesure R3 - Activer le démarrage sécurisé UEFI

:::danger
Recommendation de niveau intermédiaire (MI)
:::

Le démarrage sécurisé UEFI (*Secure Boot*) vérifie que les programmes lancés au début du démarrage sont bien autorisés. Seuls les codes signés, comme le chargeur de démarrage ou un noyau Linux au format EFI, peuvent s’exécuter. Si un code n’a pas une signature reconnue, l’UEFI bloque son chargement.

Ainsi, il est recommandé d'activer le *Secure Boot* associé à sa distribution d'OS.

### Mesure R5 - Configurer un mot de passe pour le chargeur de démarrage

:::danger
Recommendation de niveau intermédiaire (MI)
:::

Protéger GRUB avec un mot de passe empêche la modification non autorisée des paramètres de démarrage. Cela bloque l’accès aux options sensibles du noyau et empêche le contournement de politiques de sécurité.

Pour cela, nous pouvons d'abord générer un hash du mot de passe que nous souhaitons mettre avec la commande `$ grub-mkpasswd-pbkdf2`.
Il faut alors copié le hash généré et l'ajouter au fichier `/etc/grub.d/40_custom`:

set superusers="admin"
password_pbkdf2 admin <hash_généré_précédemment>

Et pour finir, nous mettons à jour le GRUB : `$ update-grub
`
### Mesure R8 - Paramétrer les options de configuration de la mémoire

:::danger
Recommendation de niveau intermédiaire (MI)
:::

Certaines options du noyau permettent de renforcer la gestion mémoire et de limiter les attaques exploitant les failles matérielles. Elles doivent être ajoutées à la ligne de commande du noyau via GRUB.

$ nano /etc/default/grub
GRUB_CMDLINE_LINUX="l1tf=full,force page_poison=on pti=on slab_nomerge=yes slub_debug=FZP spec_store_bypass_disable=seccomp spectre_v2=on mds=full,nosmt mce=0 page_alloc.shuffle=1 rng_core.default_quality=500"
$ update-grub

### Mesure R9 - Paramétrer les options de configuration du noyau

:::danger
Recommendation de niveau intermédiaire (MI)
:::

Pour renforcer la sécurité du noyau, certaines options doivent être définies dans /etc/sysctl.conf.
Elles restreignent l’accès à des interfaces sensibles comme dmesg, perf ou le BPF, et activent des protections essentielles.

$ nano /etc/sysctl.conf
kernel.dmesg_restrict=1
kernel.kptr_restrict=2
kernel.pid_max=65536
kernel.perf_cpu_time_max_percent=1
kernel.perf_event_max_sample_rate=1
kernel.perf_event_paranoid=2
kernel.randomize_va_space=2
kernel.sysrq=0
kernel.unprivileged_bpf_disabled=1
kernel.panic_on_oops=1
$ sysctl -p

### Mesure R11 - Activer et configurer le LSM Yama

:::danger
Recommendation de niveau intermédiaire (MI)
:::

Le module Yama limite l’usage de ptrace, empêchant la récupération de données sensibles dans la mémoire d’autres processus.

Pour ajouter dans GRUB la directive d’activation :

$ nano /etc/default/grub
GRUB_CMDLINE_LINUX="security=yama"

Et pour la restriction dans `sysctl.conf` :

$ nano /etc/sysctl.conf
kernel.yama.ptrace_scope=1

Enfin, pour appliquer les modifications :

$ sysctl -p
$ update-grub

### Mesure R12 - Activer et configurer les options de configuration du réseau IPv4

:::danger
Recommendation de niveau intermédiaire (MI)
:::

Pour un serveur qui n'effectue pas de routage, il est recommandé d'avoir une configuration IPv4 minimaliste.

$ nano /etc/sysctl.conf
net.core.bpf_jit_harden=2
net.ipv4.ip_forward=0
net.ipv4.conf.all.accept_local=0
net.ipv4.conf.all.accept_redirects=0
net.ipv4.conf.default.accept_redirects=0
net.ipv4.conf.all.secure_redirects=0
net.ipv4.conf.default.secure_redirects=0
net.ipv4.conf.all.accept_source_route=0
net.ipv4.conf.default.accept_source_route=0
net.ipv4.conf.all.arp_filter=1
net.ipv4.conf.all.arp_ignore=2
net.ipv4.conf.all.route_localnet=0
net.ipv4.conf.all.drop_gratuitous_arp=1
net.ipv4.conf.default.rp_filter=1
net.ipv4.conf.all.rp_filter=1
net.ipv4.conf.all.send_redirects=0
net.ipv4.conf.default.send_redirects=0
net.ipv4.icmp_ignore_bogus_error_responses=1
net.ipv4.ip_local_port_range=32768 65535
net.ipv4.tcp_rfc1337=1
net.ipv4.tcp_syncookies=1

De même que les précédentes mesures, nous appliquons la configuration modifiée avec `sysctl -p`.

### Mesure R13 - Désactiver le plan IPv6

:::danger
Recommendation de niveau intermédiaire (MI)
:::

La plupart du temps, les systèmes d'informations n'utilisant que IPv4, il est nécessaire de ne pas laisser actif IPv6.

$ nano /etc/default/grub
GRUB_CMDLINE_LINUX = ipv6.disable=1

$ nano /etc/sysctl.conf
net.ipv6.conf.default.disable_ipv6=1
net.ipv6.conf.all.disable_ipv6=1

$ update-grub
$ sysctl -p

### Mesure R14 - Paramétrer les otpions de configuration des systèmes de fichiers

:::danger
Recommendation de niveau intermédiaire (MI)
:::

Ces options limitent les attaques via liens symboliques, liens durs ou fichiers temporaires, notamment dans les répertoires comme `/tmp`.

$ nano /etc/sysctl.conf
fs.suid_dumpable=0
fs.protected_fifos=2
fs.protected_regular=2
fs.protected_symlinks=1
fs.protected_hardlinks=1

$ sysctl -p

### Mesure R28 - Partitionnement type

:::danger
Recommendation de niveau intermédiaire (MI)
:::
La recommandation R28 de l’ANSSI insiste sur l’importance d’un partitionnement durci afin de renforcer la sécurité du système.
En production, il est recommandé de séparer différentes zones sensibles du système de fichiers (telles que /var, /tmp, /home, /srv ou encore /boot) et d’appliquer des options de montage de sécurité comme nosuid, nodev ou noexec.
Ces mesures permettent de limiter l’impact d’une compromission, d’empêcher l’exécution de fichiers malveillants dans des répertoires non prévus à cet effet, et de réduire les risques d’escalade de privilèges.

Dans notre environnement de TP, l’installation Debian est volontairement simplifiée :
elle repose sur une partition racine (/) et une partition swap, avec une partition /boot distincte.Notre configuration n’est donc pas entièrement conforme aux exigences de la recommandation R28, mais cela est normal et volontaire dans le contexte du TP, afin de simplifier l’installation et de ne pas complexifier la configuration du système.

### Mesure R30 - Désactiver les comptes utilisateur inutilisés

:::danger
Recommendation de niveau minimal (M)
:::
Cette recommandation impose de désactiver tous les comptes utilisateur inutilisés afin de réduire les risques d’accès non autorisé. Sur notre machine Debian, une vérification des comptes via ` m/etc/passwd` montre que seuls les comptes système nécessaires et notre compte utilisateur principal sont actifs. Aucun compte supplémentaire ou inactif n’est présent.

La commande grep `"sh$" /etc/passwd` confirme que seuls les comptes root et safa disposent d’un shell de connexion.

Le compte safa n’est pas désactivé car il s’agit du compte utilisateur principal et actif. La recommandation R30 vise uniquement les comptes inutilisés ou obsolètes, non pas les comptes légitimes. Supprimer ou désactiver safa obligerait à utiliser directement le compte root, ce qui est contraire aux bonnes pratiques de sécurité.

### Mesure R31 - Utiliser des mots de passe robustes

:::danger
Recommendation de niveau minimal (M)
:::
Cette recommandation impose l'utilisation de mots de passe robustes afin de renforcer la sécurité du système. Les mots de passe doivent avoir une longueur minimale de 12 caractères et inclure une combinaison de majuscules, minuscules, chiffres et symboles.

On a installé avec la commande ```
apt install libpam-pwquality ```
le module libpam-pwquality qui permet de vérifier la qualité des mots de passe sur Debian. Il est utilisé pour imposer des règles de complexité lors du changement de mot de passe.
Nous avons ouvert le fichier ```/etc/pam.d/common-password ``` pour ajouter une règle qui impose des mots de passe robustes. La ligne suivante a été ajoutée pour imposer des règles de complexité : `password requisite pam_pwquality.so retry=3 minlen=15 ucredit=-1 lcredit=-1 dcredit=-1 ocredit=-1`
- retry=3 : permet 3 tentatives avant de refuser un mot de passe trop faible.
- minlen=15 : impose un mot de passe d’au moins 15 caractères.
- ucredit=-1 : exige au moins une majuscule.
- lcredit=-1 : exige au moins une minuscule.
- dcredit=-1 : exige au moins un chiffre.
- ocredit=-1 : exige au moins un caractère spécial.
Mainteannt pour faire la vérification on a testé avec "passwd safa"
Le système applique bien la politique de mots de passe. Comme tu peux le voir dans l'erreur :MOT DE PASSE INCORRECT : Le mot de passe contient moins de 1 lettres en majuscule
Cela prouve que le système exige un mot de passe avec des majuscules, conformément à la configuration que nous avons mise en place (15 caractères, majuscule, minuscule, chiffre, et caractère spécial).

### Mesure R32 - Éxpirer les sessions utilisateur locales
:::danger
Recommendation de niveau intermédiare (MI)
:::

La recommandation R32 de l'ANSSI stipule que les sessions utilisateur locales (console TTY, session graphique) doivent être automatiquement verrouillées après un certain délai d'inactivité, afin de prévenir l'accès non autorisé par oubli de déconnexion.

Nous avons éditer le fichier ```/etc/profile ``` pour les sessions en ligne en ajoutant la ligne suivante à la fin du fichier pour un délai de 10 minutes ``` export TMOUT=600 ``` Cela signifie que si une session est inactive pendant 10 minutes (600 secondes), elle sera automatiquement fermée.

### Mesure R33 - Assurer l'imputabilité des actions d'administration

:::danger
Recommendation de niveau intermédiaire (MI)
:::

Assurer la traçabilité des actions d’administration (actions nécessitant des privilèges) afin de pouvoir identifier quel administrateur est à l’origine d’une action (commande, modification système), notamment en cas d’incident.

Niveau ANSSI : M I (intermédiaire)

Création de comptes administrateurs nominatifs :

   sudo adduser ad_joe

Donner le droit sudo

    usermod -aG sudo ad_joe

Journaliser la création de processus :
Dans le fichier `/etc/sudoers` :

Defaults log_output
Defaults logfile="/var/log/sudo.log"
Defaults use_pty

Activation auditd :

sudo apt install auditd audispd-plugins
sudo systemctl enable auditd
sudo systemctl start auditd

Journalisation de la création de processus (execve)

Ajout d’une règle d’audit dans le fichier `/etc/audit/rules.d/execve.rules` pour tracer toutes les exécutions de commandes, y compris celles lancées via sudo.

-a exit,always -F arch=b64 -S execve,execveat
-a exit,always -F arch=b32 -S execve,execveat

auditctl -l
ausearch -k exec_trace

Vérification

auditctl -l
ausearch -k exec_trace

### Mesure R34 - Désactiver les comptes de service
:::danger
Recommendation de niveau intermédiaire (MI)
:::

Empêcher l’utilisation interactive des comptes de service afin de réduire la surface d’attaque et limiter les risques d’accès non autorisé.

- Identification des comptes de service avec la commande `cat /etc/passwd`

- Filtrage des comptes sans shell interactif :

`grep -E '(/usr/sbin/nologin|/bin/false)' /etc/passwd`

Le compte nobody est un compte standard utilisé par de nombreux services pour exécuter des tâches à privilèges minimum. Il permet de vérifier que la configuration des comptes de service est conforme (shell non interactif, verrouillage).
`getent passwd nobody`

Résultat obtenu : `nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin`

- Désactivation des comptes services :`usermod -L -s /bin/false <compte>`

par exemple pour le compte mail: `usermod -L -s /bin/false mail`

Vérification : `passwd -S mail`
Résultat : `mail L` -> le L indique que le compte est verrouillé

### Mesure R35 - Utiliser des comptes de service uniques et exclusifs

:::danger
Recommendation de niveau intermédiaire (MI)
:::
L’objectif de cette mesure est de garantir que chaque service métier s’exécute avec un compte système dédié et exclusif, afin d’éviter le partage d’identifiants entre plusieurs services.
Cette séparation permet de limiter l’impact d’une compromission, de réduire les interactions non souhaitées entre services et d’assurer une meilleure traçabilité des actions au niveau du système d’exploitation.

- Identification des services actifs:
Les services en cours d’exécution ont été listés afin d’identifier les services métier nécessitant un compte dédié en tapant la commande :

`systemctl list-units --type=service --state=running`

Voici un exemple de service métier identifié : `ssh.service`

- Vérification du compte utilisé par les services métiers

`systemctl show ssh.service -p User`

Le résultat obtenu : `User=`

Ce résultat indique que le service s'exécute sous root par défaut ce qui n’est pas recommandé pour un service métier.

- Création de comptes de service dédiés pour le service métier identifié avec la commande : `sudo useradd --system --no-create-home --shell /usr/sbin/nologin <service>`

Dans l'exemple de ssh
`sudo useradd --system --no-create-home --shell /usr/sbin/nologin ssh`

Les fichiers d’unité systemd ont été configurés afin de forcer l’exécution du service avec son compte dédié.

`sudo systemctl edit ssh.service`

   User=sshd
   Group=ssh

### Mesure R36 - Modifier la valeur par défaut de UMASK
:::danger
Recommendation de niveau renforcé (MIR)
:::

L’objectif est de limiter par défaut les droits d’accès aux fichiers et répertoires nouvellement créés afin d’empêcher l’accès non autorisé et d’appliquer le principe du moindre privilège dès la création des ressources.

Modification dans le fichier `/etc/login.defs` :

`sudo nano /etc/login.defs`

Modifier ou ajouter la ligne suivante : `UMASK 0027`

Vérification et adaptation du fichier /etc/profile :

`sudo nano /etc/profile`

Ajout : `umask 0027`

### Mesure R37 - Utiliser des fonctionnalités de contrôle d'accès obligatoire MAC

:::danger
Recommendation de niveau renforcé (MIR)
:::

L’objectif de la recommandation R37 est de renforcer la sécurité du système en ajoutant un contrôle d’accès obligatoire (MAC) en complément du modèle classique Unix DAC (Discretionary Access Control).

Vérification que AppArmor est présent et activé

dpkg -l | grep -E 'apparmor|apparmor-utils'
systemctl status apparmor

Vérifier l’état des profils avec la commande :`aa-status`

Activer un profil existant :

- Lister les profils disponibles :`ls /etc/apparmor.d/` ,
- Mettre un profil en enforce :`aa-enforce /etc/apparmor.d/usr.sbin.sshd`
- La vérification : `aa-status | grep -i sshd`

Générer un profil pour un service sans profil:
`aa-genprof /usr/sbin/nom-du-service`

Puis :

aa-enforce /etc/apparmor.d/usr.sbin.nom-du-service
aa-status | grep -i nom-du-service

### Mesure R38 - Créer un groupe dédié à l'usage de sudo

:::danger
Recommendation de niveau renforcé (MIR)
:::

L'objectif est de centraliser et restreindre l’utilisation de sudo aux seuls utilisateurs autorisés afin de réduire les risques d’escalade de privilèges et d’améliorer la traçabilité des actions d’administration.

- Un groupe spécifique nommé sudogrp est créé afin de regrouper tous les utilisateurs autorisés à utiliser sudo avec la commande : `sudo groupadd sudogrp`

- Ajouter des utilisateurs autorisés au groupe par :

sudo usermod -aG sudogrp ad_john
sudo usermod -aG sudogrp ad_joe

- L’exécution du binaire sudo est limitée aux membres du groupe dédié. Seul root et les membres du groupe sudogrp peuvent exécuter sudo :

sudo chown root:sudogrp /usr/bin/sudo
sudo chmod 4750 /usr/bin/sudo 

- Le groupe dédié est explicitement autorisé dans le fichier /etc/sudoers :
`sudo visudo` puis `%sudogrp ALL=(ALL:ALL) ALL`

### Mesure R39 - Modifier les directives de configuration sudo
:::danger
Recommendation de niveau intermédiaire (MI)
:::

L’objectif de la mesure R39 est de durcir la configuration de sudo afin de limiter les possibilités de contournement, réduire la surface d’attaque et renforcer la traçabilité des commandes exécutées avec privilèges élevés.

Le fichier `/etc/sudoers` est modifié exclusivement à l’aide de visudo afin d’éviter toute erreur de syntaxe bloquante : `sudo visudo`

Les directives suivantes sont activées par défaut :

Defaults noexec,requiretty,use_pty,umask=0077
Defaults ignore_dot,env_reset

Rôle des directives :
- `noexec` : empêche l’exécution de sous-commandes via des binaires lancés par sudo
- `requiretty` : impose l’utilisation d’un terminal de connexion
- `use_pty` : force l’exécution des commandes sudo dans un pseudo-terminal
- `umask=0077` : applique un masque de création de fichiers restrictif
- `ignore_dot` : ignore le répertoire courant (.) dans le $PATH
- `env_reset` : réinitialise l’environnement lors de l’exécution de sudo

### Mesure R40 - Utiliser des utilisateurs cibles non-privilégiés pour les commandes sudo
:::danger
Recommendation de niveau intermédiaire (MI)
:::

L’objectif est de réduire l’impact d’une compromission en évitant, autant que possible, l’exécution des commandes sudo en tant que root.
Lorsqu’une commande ne nécessite pas de privilèges élevés, elle doit être exécutée avec les droits d’un utilisateur non privilégié, afin de limiter les possibilités d’escalade et les effets de bord.

- Chaque utilisateur cible correspond à un périmètre fonctionnel précis:

sudo useradd -r -s /usr/sbin/nologin -G systemd-journal svc-journal
sudo useradd -r -s /usr/sbin/nologin svc-maintenance
sudo useradd -r -s /usr/sbin/nologin svc-backup

- Accès aux journaux système, un fichier de configuration dédié est créé :
`sudo visudo -f /etc/sudoers.d/90-svc-journal`

Ces règles permettent la consultation de journaux explicitement listés, exécutée sous l’utilisateur non privilégié svc-journal, sans recours à root:

Cmnd_Alias JOURNAL_CMDS = /usr/bin/journalctl --no-pager -u nginx.service
ad_john ALL=(svc-journal) JOURNAL_CMDS
ad_joe   ALL=(svc-journal) JOURNAL_CMDS

Le même principe est appliqué aux opérations de maintenance et de sauvegarde, avec des utilisateurs cibles distincts et des commandes explicitement autorisées, afin de séparer les périmètres fonctionnels et de limiter les privilèges accordés.

### Mesure R41 : Limiter l'utilisation de commandes nécessitant la directive EXEC
:::danger
Recommendation de niveau renforcé (MIR)
:::

L’objectif est de réduire au strict minimum les commandes pouvant lancer un sous-processus via la directive EXEC dans sudoers afin d’éviter les escalades de privilèges.

Sur la machine virtuelle, les fichiers `/etc/sudoers` et `/etc/sudoers.d/*` ont été inspectés afin d’identifier toute règle pouvant permettre l’exécution indirecte de commandes. Les règles reposant sur des listes d’interdiction, telles que `!/bin/sh`, ont été supprimées car elles sont facilement contournables.

À la place, seules les commandes strictement nécessaires ont été autorisées pour chaque utilisateur. Par exemple, l’utilisateur ad_john ne peut utiliser sudo que pour redémarrer le service Nginx :

`ad_john ALL=(root) /usr/bin/systemctl restart nginx`

Cette approche par liste blanche limite les possibilités de contournement et renforce le principe du moindre privilège.

### Mesure R42 : Bannir les négations dans les spécifications sudo
:::danger
Recommendation de niveau intermédiaire (MI)
:::
Le but de cette mesure est d’éviter les règles ambiguës dans la configuration de sudo.

Les fichiers `/etc/sudoers` et `/etc/sudoers.d/*` ont été inspectés à l’aide de visudo afin d’identifier la présence de règles utilisant des négations (!commande).

`sudo visudo`

Les règles de ce type ont été supprimées, car elles sont facilement contournables et ne garantissent pas une restriction effective des privilèges.
Une approche par liste blanche est utilisée à la place, consistant à autoriser uniquement les commandes strictement nécessaires.

### Mesure R43 : Préciser les arguments dans les spécification sudo
:::danger
Recommendation de niveau intermédiaire (MI)
:::

Cette mesure vise à rendre les règles sudo strictes, lisibles et non contournables, en imposant la spécification explicite des arguments autorisés pour chaque commande.

Un fichier dédié a été créé dans `/etc/sudoers.d/` afin d’isoler les règles associées à l’utilisateur concerné :
`sudo visudo -f /etc/sudoers.d/10-ad_john`

Les règles suivantes ont été définies pour ad_john, en limitant l’exécution à des commandes précises avec arguments explicitement définis, sans utilisation de wildcard :

ad_john ALL=(root) /bin/dmesg ""
ad_john ALL=(root) /usr/bin/journalctl --no-pager -u nginx.service
ad_john ALL=(root) /usr/bin/systemctl status nginx.service

L’utilisation de la chaîne vide "" permet d’interdire tout argument supplémentaire pour la commande `dmesg`, conformément aux recommandations de l’ANSSI.

Afin d’éviter l’exécution d’éditeurs de texte avec les privilèges root, l’édition des fichiers de configuration est réalisée via sudoedit, qui permet à l’éditeur de s’exécuter avec les droits de l’utilisateur courant :

`ad_john ALL=(root) sudoedit /etc/nginx/nginx.conf`

### Mesure R44 : Préciser les arguments dans les spécificatio sudo
:::danger
Recommendation de niveau intermédiaire (MI)
:::

L'objectif est d'éviter d’exécuter un éditeur detexte (vim, nano, etc.) avec les privilèges root via sudo, car un éditeur est un logiciel riche pouvant permettre l’exécution de commandes internes ou l’ouverture d’autres fichiers.
La recommandation impose donc l’usage de sudoedit pour éditer des fichiers de manière plus sûre.

- Détecter les règles dangereuses du type éditeur exécuté en root.

sudo visudo
sudo ls -l /etc/sudoers.d/

Voici les règles à éviter :

ad_john ALL=(root) /usr/bin/nano /etc/nginx/nginx.conf
ad_john ALL=(root) /usr/bin/vim /etc/ssh/sshd_config

- Création d’une règle restrictive sudoedit :
`sudo visudo -f /etc/sudoers.d/20-sudoedit-admin-alice`

Contenu ajouté

`ad_john ALL=(root) sudoedit /etc/nginx/nginx.conf`

Cette configuration permet à l’utilisateur d’éditer le fichier de configuration sans exécuter l’éditeur avec les privilèges root, conformément aux recommandations de l’ANSSI.

### Mesure R45 : Activer les profils des écurité AppArmor
:::danger
Recommendation de niveau renforcé (MIR)
:::
L’objectif de cette mesure est de s’assurer que tous les profils de sécurité AppArmor présents sur le système sont activés en mode enforce, afin de confiner strictement les processus et limiter leurs accès aux ressources système (fichiers, capacités, réseau).

Le mode enforce permet de bloquer effectivement les actions non autorisées, contrairement au mode complain qui se contente de journaliser.

Une fois AppArmor installé, cette commande force l’activation en mode enforce de tous les profils AppArmor disponibles :
`sudo aa-enforce /etc/apparmor.d/*`

### Mesure R50 : Restreindre les droits d'accès aux fichiers et aux répertoires sensibles
:::danger
Recommendation de niveau intermédiaire (MI)
:::

L’objectif de cette mesure est de garantir que les fichiers et répertoires sensibles ne soient accessibles qu’aux utilisateurs ayant un strict besoin d’en connaître.
Cela permet d’éviter toute lecture, modification ou suppression non autorisée de fichiers critiques du système, notamment ceux liés à l’authentification et à la configuration.

Les fichiers sensibles du système (authentification, configuration, clés, certificats) doivent être propriété de root et disposer de droits d’accès stricts.

- Vérification des droits existants :`ls -l /etc/passwd /etc/shadow /etc/sudoers`

- Application des droits qui empêchent tout accès aux utilisateurs non autorisés.

sudo chown root:root /etc/passwd /etc/shadow /etc/sudoers
sudo chmod 600 /etc/passwd
sudo chmod 600 /etc/shadow
sudo chmod 600 /etc/sudoers

- Fichiers applicatifs accessibles à un service dédié par exemple Web

sudo chown www-data:www-data /var/www/html/config.php
sudo chmod 640 /var/www/html/config.php

### Mesure R51 : Changer les secrets et droits d'accès dès l'installation
:::danger
Recommendation de niveau renforcé (MIR)
:::
L’objectif est de s’assurer que tous les secrets et fichiers sensibles liés à l’authentification soient correctement configurés dès l’installation du système, et que tout secret par défaut soit remplacé immédiatement.
Cela permet d’éviter l’exploitation de mots de passe, clés ou configurations par défaut, souvent connues publiquement et facilement exploitables.

- Changement des mots de passe : `sudo passwd root`
Cette commande permet de remplacer tout mot de passe par défaut par un mot de passe robuste.

- Vérification et protection des clés SSH du système: `ls -l /etc/ssh/ssh_host_*`

- Régénération des clés SSH :`sudo dpkg-reconfigure openssh-server`

- Vérification et correction des droits d’accès
Les fichiers sensibles doivent être accessibles uniquement par les utilisateurs autorisés.

sudo chmod 600 /etc/shadow
sudo chmod 600 /etc/ssh/ssh_host_*
sudo chown root:root /etc/ssh/ssh_host_*

### Mesure R52 : Restreindreles accès aux sockets et aux pipes nommées
:::danger
Recommendation de niveau intermédiaire (MI)
:::

L’objectif est de garantir que les sockets locales et les pipes nommées utilisés pour la communication entre processus ne soient accessibles qu’aux utilisateurs ou services autorisés.
Une mauvaise configuration des droits peut permettre à un processus non autorisé d’interagir avec un service sensible, voire de détourner son fonctionnement.

Les commandes suivantes ont été utilisées afin d’identifier les sockets locales, les ressources IPC et les permissions associées :

`ss -xp ` # liste les sockets Unix locales et les processus associés
`ipcs` # affiche les ressources IPC
`ls -l /dev/shm ` # vérifie les permissions des mémoires partagées
`lsof | grep unix`

Les répertoires hébergeant des sockets locales ont été vérifiés afin de s’assurer qu’ils ne sont pas accessibles en écriture globale.

Les sockets sont hébergées dans des répertoires dédiés sous `/run` ou `/var/run`, avec des permissions restrictives qui garantissent que seuls le service concerné et l’administrateur peuvent accéder aux sockets et pipes nommées.

chmod 700 /run/<service>
chown <service_user>:<service_group> /run/<service>

### Mesure R53 : Éviter les fichiers ou répertoires sans utilisateur ou sans groupe connu
:::danger
Recommendation de niveau minimal (M)
:::

L’objectif de cette mesure est d’identifier et de corriger les fichiers ou répertoires ne possédant plus de propriétaire ou de groupe valide sur le système.
Ces situations peuvent survenir après la suppression d’un compte utilisateur ou d’un groupe et représentent un risque de sécurité, car ces fichiers peuvent être réattribués automatiquement à un nouvel utilisateur ou groupe lors de leur création.

La commande suivante a été utilisée pour lister l’ensemble des fichiers ne disposant plus d’un utilisateur ou d’un groupe associé :

`find / -type f \( -nouser -o -nogroup \) -ls 2>/dev/null`

Aucun élément orphelin critique n’a été détecté. La configuration est donc conforme à la recommandation ANSSI R53. En cas de détection, les éléments concernés auraient été réattribués à un utilisateur ou à un groupe légitime et, pour les répertoires accessibles en écriture, protégés par l’activation du sticky bit afin d’empêcher toute suppression ou modification abusive

### Mesure R54 : Activer le sticky bit sur les répertoires inscriptibles
:::danger
Recommendation de niveau minimal (M)
:::

L’objectif est d’empêcher qu’un utilisateur puisse supprimer ou modifier les fichiers appartenant à d’autres utilisateurs dans les répertoires accessibles en écriture par tous, notamment les répertoires temporaires.
Le sticky bit permet de garantir que seul le propriétaire du fichier ou l’utilisateur root peut supprimer ou renommer un fichier, même si le répertoire est modifiable par tous.

Cette commande permet d’identifier les répertoires accessibles en écriture par tous et ne disposant pas du sticky bit :
`-find / -type d \( -perm -0002 -a ! -perm -1000 \) -ls 2>/dev/null`

Activation du sticky bit :Lorsque des répertoires légitimes sont identifiés exemple /tmp, le sticky bit est activé :

sudo chmod +t /chemin/du/répertoire
sudo chmod +t /tmp

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

sudo apt install libpam-modules

Dans `/etc/security/namespace.conf` :

/tmp      /tmp-inst/    level      root,adm

Dans `/etc/pam.d/sshd` :

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 :

sudo find / -type f -perm /6000 -ls

Pour désactiver un binaire inutile :

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

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

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` :

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 :

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`

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`) :

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` :

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` :

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 :

sudo apt install auditd

Activation de règles :

-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

sudo apt install aide
sudo aideinit
sudo cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db

Planification hebdomadaire :

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

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` :

AddressFamily inet
ListenAddress 0.0.0.0

Activation du firewall minimal (UFW) :

sudo apt install ufw
sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enable

---
## Usage sécurisé d'(Open)SSH

### Mesure R1 - Désactivation de SSHv1

Bien que le protocole SSH version 1 (SSHv1) soit désactivé par défaut dans les implémentations modernes de SSH, il est crucial de vérifier la configuration sur les systèmes plus anciens. Cette version est obsolète et présente des failles de sécurité majeures qui sont résolues avec la version 2 de son implémentation, SSHv2.

$ ssh -1 user@127.0.0.1
SSH protocol v.1 i no longer supported

### Mesures R7, R8, R9 et R10 - Préférences algorithmiques pour le chiffrement asymétrique

La sécurité d'un service SSH repose sur la sélection d'algorithmes robustes, car les clés d'un serveur sont peu renouvelées. Le choix initial des clés est donc essentiel.

Ainsi, les recommandations de l'ANSSI sont les suivantes :
- L'usage de clés DSA est déprécié,
- La taille minimale d'une clé RSA doit être de 2048 bits,
- La taille minimale d'une clé ECDSA doit être de 256 bits.

À noter qu'il est recommandé d'utiliser ECDSA plutôt que RSA si l'algorithme est supporté à la fois par le client et le serveur.

Pour générer une paire de clé ECDSA de taille correcte : `ssh-keygen -t ecdsa -b 256`

### Mesure R13, R14 - Protection des clés privées

Le service d'authentification repose sur la cryptographie asymétrique, il est donc critique d'assurer la sécurité des clés privées.
En ce qui concerne les clés du serveur, elles doivent être uniquement lisible par le service sshd lui-même, autrement dit par l'utilisateur root.

$ ls -la ssh_host_ecdsa_key ssh_host_rsa_key
-rw-------
-rw-------

Concernant les clés privées utilisateurs, la mesure est la même qu'exposée pour les clés serveurs, à un détail près que la clé utilisateur doit être protégée par un mot de passe seulement connu de cet utilisateur.

ssh-keygen -t ecdsa -b 256
# Demande la passphrase de l'utilisateur
ssh-keygen -t ecdsa -b 256 -p
# Demande l'ancienne passphrase avant de rentrer la nouvelle

À noter qu'il est possible de changer sa passphrase avec l'option `-p`, comme ci-dessus.

En cas de perte ou de vol de la clé privée, la protection du fichier avec un mot de passe permet d'avoir suffisament de temps afin de révoquer la clé concernée (à condition d'avoir un mot de passe robuste, cf. [Recommandations relatives à l'authentification multifacteur et aux mots de passe](https://cyber.gouv.fr/publications/recommandations-relatives-lauthentification-multifacteur-et-aux-mots-de-passe))

Pour le chiffrement de cette clé par mot de passe, il est fortement recommandé d'utiliser AES-128-CBC : `ssh-keygen -t ecdsa -b 256 -Z aes128-cbc`

Du côté serveur, les accès au répertoire `∼/.ssh/` et ses fichiers doivent être protégés. De ce fait, le serveur sshd doit vérifier la conformité des modes et droits des fichiers de l’utilisateur avant de le laisser ouvrir une session. Pour cela, il faut décommenter la ligne `StrictModes Yes` du fichier de configuration `/etc/ssh/sshd_config`.

### Mesures R15 - Préférences algorithmiques pour le chiffrement symétrique

Une fois les parties mutuellement authentifiées avec le chiffrement asymétrique, le canal de communication est chiffré avec le chiffrement symétrique et l'intégrité des échanges est vérifiée avec un algorithme de hashage.

Les recommandations de l'ANSSI sont les suivantes :
- AES-(128, 192, 256) en mode CTR
- HMAC SHA-(256, 512)

Pour les versions récentes, privilégiez le mode ETM (Encrypt-Then-Mac), tandis que le SHA-1 peut être conservé pour assurer la compatibilité avec d’anciennes versions. Il est essentiel que la liste des algorithmes autorisés soit définie au préalable entre le client et le serveur.
La configuration s’effectue directement dans les fichiers ssh_config (côté client) et sshd_config (côté serveur):

Ciphers aes256-ctr,aes192-ctr,aes128-ctr
MACs [e-mail],[e-mail]

# Pour les anciennes versions
MACs hmac-sha2-512,hmac-sha2-256,hmac-sha1

### Mesure R16 – Séparation de privilèges

La séparation de privilèges limite l’impact d’une vulnérabilité dans le service SSH.

UsePrivilegeSeparation sandbox

### Mesures R17 et R18 – Authentification et principe de moindre privilège

L’authentification doit être robuste et limiter autant que possible les tentatives d’accès non autorisées. Les droits d’un utilisateur doivent suivre le principe de moindre privilège, notamment en contrôlant :
- les mécanismes d’authentification (privilégier par clés),
- le nombre de tentatives,
- le temps accordé pour s’authentifier,
- l’origine des connexions.

PermitEmptyPasswords no
PasswordAuthentication no
ChallengeResponseAuthentication no

MaxAuthTries 2
LoginGraceTime 30

### Mesure R21 – Interdire l’accès SSH direct au compte root

Le compte `root` ne doit pas être accessible directement afin d’assurer une traçabilité complète des actions d’administration en utilisant des comptes dédiés.
De plus, afficher les informations de dernière connexion permet à l’utilisateur de détecter une activité suspecte.

PermitRootLogin no
PrintLastLog yes

### Mesure R22 – Restriction de connexions

L’accès au service SSH doit être limité uniquement aux utilisateurs ou groupes ayant un besoin justifié, notamment en restreignant les adresses IP d’origine.

AllowUsers admin@192.168.1.0/24
# ou bien
AllowGroups ssh-admins

### Mesure R23 – Restriction de l’environnement utilisateur

Les variables d’environnement peuvent altérer le comportement des programmes et introduire des failles de sécurité. Leur modification doit être bloquée par défaut.

PermitUserEnvironment no

### Mesures R27 et R28 – Désactivation des redirections de flux

Les redirections TCP et X11 peuvent être détournées à des fins malveillantes. Elles doivent être désactivées sauf nécessité opérationnelle clairement identifiée.

AllowTcpForwarding no
X11Forwarding no

---

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

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 :

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 :

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.