# Durcissement d'un système GNU/Linux
## Introduction
Dans cette partie nous allons étudier et mettre en place les recommandations de l'ANSSI concernant la configuration d'un système GNU/Linux. Ces recommandations sont classées par niveau de durcissement :
- **Niveau minimal** : à mettre en oeuvre systématiquement sur tout système Linux
- **Niveau intermédiaire** : correspond généralement à des services protégés par plusieurs couches de sécurité de niveau supérieur
- **Niveau renforcé** : généralement pour des systèmes exposés à des flux non authentifiés ou de sources nombreuses
- **Niveau élevé** : correspond à des systèmes hébergeant des données sensibles accessibles depuis des réseaux non authentifiés ou peu contrôlés
Chaque recommendation sera noté 'Rx', où 'x' est le numéro de la recommendation ANSSI.
## Table des matières
- [Durcissement d'un système GNU/Linux](#durcissement-dun-système-gnulinux)
- [Introduction](#introduction)
- [Table des matières](#table-des-matières)
- [Recommandations - Niveau Minimal](#recommandations---niveau-minimal)
- [R1 - Minimisation des services installés](#r1---minimisation-des-services-installés)
- [R5 - Principe de défense en profondeur](#r5---principe-de-défense-en-profondeur)
- [R8 - Mises à jour régulières](#r8---mises-à-jour-régulières)
- [R15 - Choix des dépôts de paquets](#r15----choix-des-dépôts-de-paquets)
- [R18 - Robustesse du mot de passe administrateur](#r18---robustesse-du-mot-de-passe-administrateur)
- [R30 - Applications utilisant PAM](#r30----applications-utilisant-pam)
- [R32 - Protection des mots de passe stockés](#r32---protection-des-mots-de-passe-stockés)
- [R37 - Exécutables avec bits setuid et setgid](#r37---exécutables-avec-bits-setuid-et-setgid)
- [R42 - Services et démons résidents en mémoire](#r42----services-et-démons-résidents-en-mémoire)
- [R59 - Authentification des utilisateurs exécutant sudo](#r59---authentification-des-utilisateurs-exécutant-sudo)
- [Recommandations - Niveau Intermédiaire](#recommandations---niveau-intermédiaire)
- [R2 - Minimisation de la configuration](#r2---minimisation-de-la-configuration)
- [R9 - Configuration matérielle](#r9---configuration-matérielle)
- [R10 - Architecture 32 et 64 bits](#r10---architecture-32-et-64-bits)
- [R12 - Partitionnement type](#r12---partitionnement-type)
- [R14 - Installation de paquets réduite au strict nécessaire](#r14---installation-de-paquets-réduite-au-strict-nécessaire)
- [R19 - Imputabilité des opérations d'administration](#r19---imputabilité-des-opérations-dadministration)
- [R21 - Durcissement et surveillance des services soumis à des flux arbitraires](#r21---durcissement-et-surveillance-des-services-soumis-à-des-flux-arbitraires)
- [R22 - Paramétrage des sysctl réseau](#r22---paramétrage-des-sysctl-réseau)
- [R23 - Paramétrage des sysctl système](#r23---paramétrage-des-sysctl-système)
- [R27 - Désactivation des comptes de services](#r27---désactivation-des-comptes-de-services)
- [R31 - Sécurisation des services réseau d'authentification PAM](#r31---sécurisation-des-services-réseau-dauthentification-pam)
- [R33 - Sécurisation des accès aux bases utilisateurs distantes](#r33---sécurisation-des-accès-aux-bases-utilisateurs-distantes)
- [R34 - Séparation des comptes système et d'administrateur de l'annuaire](#r34---séparation-des-comptes-système-et-dadministrateur-de-lannuaire)
- [R36 - Droits d'accès aux fichiers de contenu sensible](#r36---droits-daccès-aux-fichiers-de-contenu-sensible)
- [R39 - Répertoires temporaires dédiés aux comptes](#r39---répertoires-temporaires-dédiés-aux-comptes)
- [R40 - Sticky bit et droits d'accès en écriture](#r40---sticky-bit-et-droits-daccès-en-écriture)
- [R41 - Sécurisation des accès pour les sockets et pipes nommées](#r41---sécurisation-des-accès-pour-les-sockets-et-pipes-nommées)
- [R43 - Durcissement et configuration du service syslog](#r43---durcissement-et-configuration-du-service-syslog)
- [R44 - Cloisonnement du service syslog par chroot](#r44---cloisonnement-du-service-syslog-par-chroot)
- [R46 - Journaux d'activité de service](#r46---journaux-dactivité-de-service)
- [R47 - Partition dédiée pour les journaux](#r47---partition-dédiée-pour-les-journaux)
- [R48 - Configuration du service local de messagerie](#r48---configuration-du-service-local-de-messagerie)
- [R55 - Cage chroot et privilèges d'accès du service cloisonné](#r55---cage-chroot-et-privilèges-daccès-du-service-cloisonné)
- [R56 - Activation et utilisation de chroot par un service](#r56---activation-et-utilisation-de-chroot-par-un-service)
- [R57 - Groupe dédié à l'usage de sudo](#r57---groupe-dédié-à-lusage-de-sudo)
- [R58 - Directives de configuration sudo](#r58---directives-de-configuration-sudo)
- [R60 - Privilèges des utilisateurs cibles pour une commande sudo](#r60---privilèges-des-utilisateurs-cibles-pour-une-commande-sudo)
- [R62 - Du bon usage de la négation dans une spécification sudo](#r62---du-bon-usage-de-la-négation-dans-une-spécification-sudo)
- [R63 - Arguments explicites dans les spécifications sudo](#r63---arguments-explicites-dans-les-spécifications-sudo)
- [R64 - Du bon usage de sudoedit](#r64---du-bon-usage-de-sudoedit)
- [Recommandations - Niveau Renforcé](#recommandations---niveau-renforcé)
- [R3 - Principe de moindre privilège](#r3---principe-de-moindre-privilège)
- [R6 - Cloisonnement des services réseau](#r6---cloisonnement-des-services-réseau)
- [R7 - Journalisation de l'activité des services](#r7---journalisation-de-lactivité-des-services)
- [R13 - Restrictions d'accès sur le dossier /boot](#r13---restrictions-daccès-sur-le-dossier-boot)
- [R16 - Dépôts de paquets durcis](#r16---dépôts-de-paquets-durcis)
- [R17 - Mot de passe du chargeur de démarrage](#r17---mot-de-passe-du-chargeur-de-démarrage)
- [R20 - Installation d'éléments secrets ou de confiance](#r20---installation-déléments-secrets-ou-de-confiance)
- [R24 - Désactivation du chargement des modules noyau](#r24---désactivation-du-chargement-des-modules-noyau)
- [R25 - Configuration sysctl du module Yama](#r25---configuration-sysctl-du-module-yama)
- [R26 - Désactivation des comptes utilisateurs inutilisés](#r26---désactivation-des-comptes-utilisateurs-inutilisés)
- [R28 - Unicité et exclusivité des comptes de services](#r28---unicité-et-exclusivité-des-comptes-de-services)
- [R29 - Délai d'expiration de sessions utilisateurs](#r29---délai-dexpiration-de-sessions-utilisateurs)
- [R35 - Valeur de umask](#r35---valeur-de-umask)
- [R38 - Exécutables setuid root](#r38---exécutables-setuid-root)
- [R50 - Journalisation de l'activité par auditd](#r50---journalisation-de-lactivité-par-auditd)
- [R53 - Restriction des accès des services déployés](#r53---restriction-des-accès-des-services-déployés)
- [R54 - Durcissement des composants de virtualisation](#r54---durcissement-des-composants-de-virtualisation)
- [R61 - Limitation du nombre de commandes nécessitant l'option EXEC](#r61---limitation-du-nombre-de-commandes-nécessitant-loption-exec)
- [Recommandations - Niveau Elevé](#recommandations---niveau-elevé)
- [R4 - Utilisation des fonctionnalités de contrôle d'accès](#r4---utilisation-des-fonctionnalités-de-contrôle-daccès)
- [R11 - Directive de configuration de l'IOMMU](#r11---directive-de-configuration-de-liommu)
## Recommandations - Niveau Minimal
### R1 - Minimisation des services installés
Cette recommandation vise à minimiser les services activés par défaut lors de l'installation de Debian. Il est important de désactiver tout service non nécessaire au bon fonctionnement de notre système. Certains services peuvent rendre notre système plus sensible aux attaques, comme les services d'écoute réseau par exemple.
Il est possible de lister les services avec la commande `systemctl`:
```sh
$ systemctl list-unit-files | grep enabled
$ systemctl disable <service-name>
```
### R5 - Principe de défense en profondeur
La défense en profondeur repose sur une "combinaison de barrières qu'il faut garder indépendantes les unes des autres". Comme par exemple, avoir plusieurs couches de sécurité afin d'éviter une compromission totale du système suite au franchissement de la première couche.
**Authentification**
Dans notre cas, nous utiliserons deux utilisateurs, l'un ne disposant pas de droits administrateur (non présent dans le sudoers). Et l'utilisateur *root* disposant de tous les droits sur le système. Une authentification est nécessaire afin d'effectuer des commandes sensibles pour le système.
**Journalisation**
- `/var/log/secure`: Journalise tout les évènements « secure », ceux liés à la sécurité du système, y compris l'authentification.
- `/var/log/maillog`: Journalise les messages liés à la messagerie.
- `/var/log/cron`: Journalise tous les messages liés aux tâches cron.
- `/var/log/boot`: Journalise tous les messages liés au démarrage du système.
**Mécanismes de prévention d'exploitation**
Il existe des mécanismes de prévention d'exploitation activés par défaut sur les systèmes UNIX. Nous pouvons par exemple vérifier que l'ASLR (Address Space Layout Randomization) est bien activé sur le système en utilisant la commande suivante :
```sh
$ /usr/sbin/sysctl -a --pattern "randomize"
```
### R8 - Mises à jour régulières
Il est fortement recommandé d'avoir une procédure de mises à jour automatiques. Pour ce faire, il existe un utilitaire nommé `unatended-upgrades` permettant d'installer automatiquement les mises à jour de sécurité du système.
Le paquet n'est pas installé par défaut sur Debian. Il peut être installé et configuré à l'aide les commandes ci-dessous.
```sh
# Installation du paquet
apt install unattended-upgrades
# Modification du fichier de configuration
vim /etc/apt/apt.conf.d/50unattended-upgrades
```
Dans le fichier de configuration il est possible de décommenter les deux principales lignes suivantes:
- `${distro_id}:${distro_codename}-security;`: Mises à jour de sécurité automatiques
- `${distro_id}:${distro_codename}-updates`: Mises à jour des paquets recommandés automatiques
Ensuite, il est nécessaire d'appliquer les changements en reconfigurant le paquet avec la commande suivante :
```sh
/usr/sbin/dpkg-reconfigure --priority=low unattended-upgrades
```
### R15 - Choix des dépôts de paquets
Il est recommandé d'utiliser les dépôts offciels Debian. Il est possible de configurer les dépôts dans le fichier `/etc/apt/sources.list`.
### R18 - Robustesse du mot de passe administrateur
Il est indispensable d'utiliser des mots de passe robustes avec certaines exigences énoncées dans les [Recommandations de sécurité relatives aux mots de passe](https://www.ssi.gouv.fr/guide/recommandations-relatives-a-lauthentification-multifacteur-et-aux-mots-de-passe/)
Selon ce guide (R21) un mot de passe fort doit être constitué d'au moins 15 caractères. Afin de rendre le mot de passe plus robuste, il est intéressant d'utiliser un jeu de caractères le plus grand possible en intégrant des caractères spéciaux (R23) et en imposant leur utilisation.
Tout ceci peut être configuré dans le fichier de configuration PAM `/etc/pam.d/common-password`. Avant cela, on installe le paquet `libpam-pwquality` nous permettant de vérifier la complexité des mots de passe renseignées.
On utilisera les options suivantes (fournis par `libpam-pwquality`) afin de complexifier nos mots de passe:
- `ocredit`: nombre de caractères spéciaux dans le mot de passe
- `ucredit`: nombre de majuscules dans le mot de passe
- `dcredit`: nombre de nombres dans le mot de passe
- `lcredit`: nombre de minuscules dans le mot de passe
```sh
# Configuration de la longueur minimale
password [success=1 default=ignore] pam_unix.so obscure yescrypt minlen=15
# Ajout de complexité
password requisite pam_pwquality.so retry=3 ocredit=1 ucredit=1 dcredit=1 lcredit=1
```
### R30 - Applications utilisant PAM
PAM (Pluggable Authentication Modules), est un ensemble de modules permettant de configurer dynamiquement différents mécanismes d'authentification et de gestion de comptes sur un système Linux.
Le nombre d'applications utilisant PAM doit être réduit au strict minimum afin de limiter l'exposition d'éléments d'authentification sensibles.
### R32 - Protection des mots de passe stockés
Tout mot de passe doit être protégé par des mécanismes cryptographiques évitant de les exposer en clair.
- Utilisation de fonctions de hachage considérées comme sûres (SHA256 et SHA512) avec un sel assez grand et un nombre de tours important (65536).
- Fonction de dérivation de clé sur le mot de passe combinée à une fonction de hachage
- Chiffrement par clé secrète
Il est possible de configurer cela dans le fichier de configuration `/etc/pam.d/common-password`.
```sh
# Ajout du nombre de tours et choix du mécanisme de hachage
password [success=1 default=ignore] pam_unix.so obscure sha512 minlen=15 rounds=65536
^ ^
```
On configure aussi le fichier `/etc/login.defs` en ajoutant les deux lignes suivantes:
```sh
ENCRYPT_METHOD SHA512
SHA_CRYPT_MIN_ROUNDS 65536
```
### R37 - Exécutables avec bits setuid et setgid
Il est nécessaire de s'assurer que seul les programmes conçus pour être utilisés avec les bits setuid peuvent avoir ces bits de privilèges positionnés. Il est courant qu'un utilisateur puisse appeler un programme avec les privilèges `root` alors qu'il n'a à priori pas les droits. Ces programmes, en cas de vulnérabilité, seront exploités en vue de fournir les droits `root` à l'attaquant.
Il est possible de lister les fichiers disposant de droits setuid ou setgid avec la commande `find / -type f -perm /6000 -ls 2>/dev/null` (ou 6000 correspond à setuid et setgid).
```sh
$ find / -type f -perm /6000 -ls 2>/dev/null
19251 1332 -rwsr-xr-x 1 root root 1360680 Jul 13 17:04 /usr/sbin/exim4
65 40 -rwxr-sr-x 1 root shadow 38912 Aug 26 20:11 /usr/sbin/unix_chkpwd
108 32 -rwxr-sr-x 1 root shadow 31160 Feb 7 2020 /usr/bin/expiry
3596 44 -rwsr-xr-x 1 root root 44632 Feb 7 2020 /usr/bin/newgrp
110 64 -rwsr-xr-x 1 root root 63960 Feb 7 2020 /usr/bin/passwd
1516 36 -rwxr-sr-x 1 root tty 35048 Jul 28 20:09 /usr/bin/wall
106 60 -rwsr-xr-x 1 root root 58416 Feb 7 2020 /usr/bin/chfn
105 80 -rwxr-sr-x 1 root shadow 80256 Feb 7 2020 /usr/bin/chage
5501 44 -rwxr-sr-x 1 root crontab 43568 Feb 22 2021 /usr/bin/crontab
4124 36 -rwsr-xr-x 1 root root 35040 Jul 28 20:09 /usr/bin/umount
3755 72 -rwsr-xr-x 1 root root 71912 Jul 28 20:09 /usr/bin/su
2419 24 -rwxr-sr-x 1 root tty 22760 Jul 28 20:09 /usr/bin/write.ul
18702 180 -rwsr-xr-x 1 root root 182600 Feb 27 2021 /usr/bin/sudo
19954 16 -rwxr-sr-x 1 root root 15208 Nov 19 2020 /usr/bin/dotlock.mailutils
4122 56 -rwsr-xr-x 1 root root 55528 Jul 28 20:09 /usr/bin/mount
12765 24 -rwxr-sr-x 1 root mail 23040 Feb 4 2021 /usr/bin/dotlockfile
107 52 -rwsr-xr-x 1 root root 52880 Feb 7 2020 /usr/bin/chsh
15996 348 -rwxr-sr-x 1 root ssh 354440 Mar 13 2021 /usr/bin/ssh-agent
109 88 -rwsr-xr-x 1 root root 88304 Feb 7 2020 /usr/bin/gpasswd
16003 472 -rwsr-xr-x 1 root root 481608 Mar 13 2021 /usr/lib/openssh/ssh-keysign
2389 52 -rwsr-xr-- 1 root messagebus 51336 Feb 21 2021 /usr/lib/dbus-1.0/dbus-daemon-launch-helper
```
Il est possible ensuite de supprimer les setuid et setgid sur les fichiers avec la commande `chmod`.
### R42 - Services et démons résidents en mémoire
Seuls les démons réseau strictement nécessaires au fonctionnement du système et duservice qu'ils rendent doivent être résidents et n'être en écoute que sur les interfaces réseau adéquates. Les autres démons doivent être désactivés et autant que possible désinstallés.
Il est possible de désactiver les démons avec la commande `update-rc.d <démon> enable|disable` où démon est le nom du démon présent dans `/etc/init.d`.
Liste des démons les plus courants à désactiver:
- portmap
- rpc.statd
- rpcbind
- dbus
- hald
- ConsoleKit
- CUPS
- PolicyKit
- avahi
- SMTP (Exim, Postfix)
- NTP (ntpd)
- DNS (Bind)
Exemple de démons pouvant être désactivés :
```sh
update-rc.d dbus disable
update-rc.d exim4 disable
update-rc.d bluetooth disable
```
### R59 - Authentification des utilisateurs exécutant sudo
Il est nécessaire d'imposer une authentification avant chaque commande nécessitant un droit `root`. L'utilisation du mot-clé `NOPASSWD` dans le fichier `/etc/sudoers` est à proscrire.
## Recommandations - Niveau Intermédiaire
### R2 - Minimisation de la configuration
Il est nécessaire de limiter au strict nécessaire les fonctionnalités configurées au niveau des services démarrés. Afin de gagner en sécurité et en sûreté, tout objet ou entité gérée par un système de dispose que des droits strictements nécessaires à son exécution.
### R9 - Configuration matérielle
Il est conseillé d'appliquer les recommandations matérielles de la note technique "[Recommandations de configuration matérielle de postes clients etserveurs x86](https://www.ssi.gouv.fr/administration/guide/recommandations-de-configuration-materielle-de-postes-clients-et-serveurs-x86/) " rédigée par l'ANSSI
**R3** - Si le mode 32 bits est utilisé, le processeur doit être capable de supporter PAE.
PAE (Physical Address Extension) est une fonctionnalité permettant d'adresser jusqu'à 64Go de mémoire physique sur des systèmes 32 bits (limité à 4Go normalement).
**R5** - Il est recommandé d'utiliser un processeur capable de supporter la fonctionnalité SMEP.
La fonctionnalité SMEP (Supervisor Mode Execution Prevention) est utilisé pour empêcher le mode superviseur d'exécuter involontairement le code de l'espace utilisateur.
**R6** - Il est recommandé d'utiliser un processeur capable de supporter la fonctionnalité SMAP.
La fonctionnalité SMAP (Supervisor Mode Access Prevention) permet d'étendre la protection SMEP aux lectures et aux écritures.
**R7** - Il est recommandé d'utiliser un processeur capable de supporter le jeu d'instruction AES-NI.
Cette instruction est aujourd'hui intégrer dans tous les processeurs. Elle permet d'améliorer la vitesse et la sécurité des applications faisant du chiffrement et du déchiffrement AES.
**R8** - Il est recommandé d'utiliser une architecture capable de fournir une source d'aléa matérielle.
Un certain nombre de mécanisme utilise l'aléa matérielle appelé `entropy` pour générer des clés de chiffrement par exemple.
**R9** - La fonction de virtualisation doit être désactivée lorsqu'elle n'est pas strictement nécessaire au bon fonctionnement du système.
**R11** - Les accès aux paramètres du BIOS doivent être protégés par un mot de passe.
**R12** - En accord avec le principe de minimisation, les composants non essentielles au bon fonctionnement du système doivent être désactivés. Cela peut-être des connecteurs externes tels que les ports USB, SATA ou éventuellement des périphériques sans-fil comme les cartes WiFi ou Bluetooth.
Pour désactiver les ports USB de la machine, il est nécessaire de modifier le fichier de configuration de `modprobe`. `modprobe` est un utilitaire permettant d'ajouter ou supprimer des modules du kernel. Il est possible de créer le fichier `/etc/modprobe.d/blacklist.conf` nous permettant de désactiver des modules.
```sh
$ vim /etc/modprobe.d/blacklist.conf
# Désactivation du module USB
blacklist usb-storage
# Désactivation de l'autorisation de la connexion d'appreil au système via USB
$ echo 0 > /sys/bus/usb/devices/usb1/authorized
$ echo 0 > /sys/bus/usb/devices/usb1/authorized_default
```
**R14** - La fonction de contrôle d'accès en exécution d'une page mémoire doit être activée dans le BIOS.
### R10 - Architecture 32 et 64 bits
Il existe deux modes de fonctionnement des processeurs:
- mode protégé (protected mode), adressage virtuel sur 32 bits (4 octets)
- mode long (long mode), adressage plus large sur 64 bits (8 octets)
Lutilisation du mode 64 bits présente des avantages par rapport au mode protégé :
- l'espace d'adressage plus important donne plus de latitude dans le choix des adresses, en particulier lorsqu'il est fait de manière aléatoire (ASLR) ;
- la présence systématique de bits de protections NX/XD (droit d'exécution mémoire) sur les pages mémoires, permettant de les déclarer non-exécutables;
- l'adressage relatif par registre `rip`, plus naturel (et performant) pour du code qui peut être chargé voire exécuté indépendamment de sa position (PIC, PIE) ;
- l'accroissement de l'espace d'adressage du noyau et des processus (de 4GiB à 128TiB) permet d'augmenter les performances de programmes nécessitant de grandes quantités de mémoire, comme certaines bases de données.
Lorsque la machine le supporte, il est recommandé d'utiliser une architecture en version 64 bits plutôt que 32 bits.
### R12 - Partitionnement type
Le partionnement recommandé est le suivant :
| Point de montage | Option | Description |
|-------------------|-----------------------|------------------------------------------------------------------------------------------------------------------------------------|
| / | sans option | Partition racine, contient le reste de l'arborescence |
| /boot | nosuid,nodev,noexec | Contient le noyau et le chargeur dedémarrage. Pas d'accès nécessaire une fois le boot terminé (sauf mise à jour) |
| /opt | nosuid,nodev | Packages additionnels au système.Montage en lecture seule si non utilisé |
| /tmp | nosuid,nodev,noexec | Fichiers temporaires. Ne doit contenir que des éléments non exécutables. Nettoyé après redémarrage oupréférablement de type tmpfs |
| /srv | nosuid,nodev | Contient des fichiers servis par un service type web, ftp, etc. |
| /home | nosuid,nodev,noexec | Contient les HOME utilisateurs. Montage en lecture seule si non utilisé |
| /proc | hidepid=2 | Contient des informations sur les processus et le système |
| /usr | nodev | Contient la majorité des utilitaires et fichiers système |
| /var | nosuid,nodev,noexec | Partition contenant des fichiers variables pendant la vie du système (mails,fichiers PID, bases de données d'un service) |
| /var/log | nosuid,nodev,noexec | Contient les logs du système |
| /var/tmp | nosuid,nodev,noexec | Fichiers temporaires conservés après extinction |
### R14 - Installation de paquets réduite au strict nécessaire
Il est nécessaire d'installer seulement les paquets nécessaires et de se limiter au strict minimum requis.
Par exemple, éviter l'installation graphique de Debian si son utilisation n'est pas nécessaire. Cela limite l'installation de nombreux paquets inutiles.
### R19 - Imputabilité des opérations d'administration
Chaque administrateur doit posséder un compte (local ou distant) afin de ne pas utiliser le compte `root` comme compte d'accès. Les opérations de changement de privilèges (`sudo` par exemple) devront reposer sur des exécutables permettant de surveiller les activités réalisées.
Il est possible de faire passer un compte utilisateur en tant que compte administrateur en configurant le fichier de configuration `/etc/sudoers`. Il est possible, dans ce fichier, de selectionner les commandes pouvant être utilisées par un utilisateur ou un groupe d'utilisateur.
### R21 - Durcissement et surveillance des services soumis à des flux arbitraires
Les services exposés à des flux non maîtrisés doivent être surveillés et particulièrement durcis. Ici, cette recommandation vise tout services disposant d'une faille ou une vulnérabilité exploitable avant une étape d'authentification.
Afin d'effectuer cette surveillance, il existe le pare-feu `iptable` configuré par défaut sur Debian pour accepter tout le trafic réseau. Dans notre cas, on autorisera seulement le trafic SSH qui est le seul nécessaire dans notre contexte.
```sh
# Drop de tout le trafic par défaut
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
# Autorisation des flux SSH entrants
iptables -A INPUT -s 10.0.2.0/24 -p TCP --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT
# Autorisation d'envoie de la réponse SSH au client
iptables -A OUTPUT -p TCP --sport 22 -m state --state ESTABLISHED -j ACCEPT
```
### R22 - Paramétrage des sysctl réseau
Les `sysctl` sont un ensemble de variables permettant d'adapter le paramétrage de l'OS et plus particulièrement de son noyau. Cette ensemble est enrichi au fur et à mesure des évolutions et améliorations apportées au système.
Ci-dessous la liste des sysctl réseau recommandées et appliquées pour un hôte de type serveur:
```sh
# Désactivation de l'IPv6
net.ipv6.conf.all.disable_ipv6 = 1
# Pas de routage entre les interfaces
net.ipv4.ip_forward = 0
# Filtrage par chemin inverse
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
# Ne pas envoyer de redirections ICMP
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
# Refuser les paquets de source routing
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
# Ne pas accepter les ICMP de type redirect
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.secure_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.default.secure_redirects = 0
# Loguer les paquets ayant des IPs anormales
net.ipv4.conf.all.log_martians = 1
# RFC 1337
net.ipv4.tcp_rfc1337 = 1
# Ignorer les réponses non conformes à la RFC 1122
net.ipv4.icmp_ignore_bogus_error_responses = 1
# Augmenter la plage pour les ports éphémères
net.ipv4.ip_local_port_range = 32768 65535
# Utiliser les SYN cookies
net.ipv4.tcp_syncookies = 1
```
### R23 - Paramétrage des sysctl système
De même que pour les sysctl réseaux, voici une liste des sysctl systèmes recommandées et appliquées pour un hôte de type serveur:
```sh
# Désactivation des SysReq
kernel.sysrq = 0
# Pas de core dump des exécutables setuid
fs.suid_dumpable = 0
# Activation de l'ASLR
kernel.randomize_va_space = 2
# Interdiction de mapper de la mémoire dans les adresses basses (0)
vm.mmap_min_addr = 65536
# Espace de choix plus grand pour les valeurs de PID
kernel.pid_max = 65536
# Obfuscation des adresses mémoire kernel
kernel.kptr_restrict = 1
# Restriction d'accès au buffer dmesg
kernel.dmesg_restrict = 1
# Restreint l'utilisation du sous système perf
kernel.perf_event_paranoid = 2
kernel.perf_event_max_sample_rate = 1
kernel.perf_cpu_time_max_percent = 1
```
### R27 - Désactivation des comptes de services
Cette mesure permet d'éviter l'ouverture d'une session utilisateur par un compte de service. Certains services peuvent se déclarer en tant que `nobody`. Quand plusieurs de ces services adopte un tel comportement, ils se retrouvent tous avec les mêmes identifiants (et privilèges).
Les comptes de services peuvent être retrouvés dans le fichier `/etc/passwd`. Si l'entrée se termine par `/bin/nologin` c'est qu'il s'agit d'un compte de service.
Une fois identifier, les comptes peuvent être désactivés avec les commandes suivantes:
```sh
# Verrouillage d'un compte
usermod -L <user>
# Désactivation de son shell de login
usermod -s /bin/false <user>
```
### R31 - Sécurisation des services réseau d'authentification PAM
Lorsque l'authentification se déroule au travers d'un service distant, le protocole d'authentification utilisé par PAM doit être sécurisé par un chiffrement du flux, une authentification du serveur ou encore en mettant en place un mécanisme d'anti-rejeu.
### R33 - Sécurisation des accès aux bases utilisateurs distantes
Lorsque les bases utilisateurs sont stockés sur un service réseau distant (type LDAP), NSS doit être configuré pour établir une liaison sécurisée permettant au minimum d'authentifier le serveur et de protéger le canal de communication.
NSS (Name Service Switch) permet de remplacer fichiers comme `/etc/passwd`, `/etc/group` ou encore `/etc/hosts` par une ou plusieurs bases de données centralisées. NSS va permettre d'effectuer des requêtes auprès de l'annuaire externe (souvent LDAP) afin de rendre les comptes visibles auprès du système.
### R34 - Séparation des comptes système et d'administrateur de l'annuaire
Il est recommandé de ne pas avoir de recouvrement de compte entre ceux utilisés par le système et ceux utilisés pour administrer l'annuaire. L'usage de comptes administrateur d'annuaire pour effectuer des requêtes d'énumération de comptes par NSS doit être prohibé.
### R36 - Droits d'accès aux fichiers de contenu sensible
Les fichiers à contenu sensible ne doivent être lisibles que par les utilisateurs ayant le strict besoin d'en connaître. Par exemple, pour les mots de passe, ceux-ci doivent être lisibles que par *root*.
Liste non-exhaustive des fichiers à contenu sensible:
- /etc/gshadow
- /etc/shadow
- /home/foo/.ssh/id_rsa
- /etc/passwd
- /etc/fstab
- /etc/inittab
- /vmlinuz
- /etc/ssh/sshd_config
- /etc/crontab
### R39 - Répertoires temporaires dédiés aux comptes
Chaque compte utilisateur ou service doit posséder son propre répertoire temporaire et en disposer exclusivement.
Les modules `pam_mktemp` et `pam_namespace` permettent de créer de manière sécurisée un fichier ou un répertoire temporaire propre à chaque utilisateur.
L'exclusivité de ces fichiers temporaires n'est pas garantie, il existe un moyen (imparfait) pour pallier au problème. Il s'agit d'activer le `sticky bit` sur le répertoire permettant de s'assurer que seul l'utilisateur qui a créé le répertoire puisse le supprimer.
### R40 - Sticky bit et droits d'accès en écriture
Le `sticky bit`, comme expliqué précédemment permet de s'assurer que seul l'utilisateur qui a créé le répertoire ou le fichier puisse le supprimer. Le sticky bit peut être appliqué grâce à la commande `chmod`.
```sh
chmod a+t <filename> # Appliquer le sticky bit
chmod a-t <filename> # Retirer le sticky bit
```
Les commandes suivantes permettent de lister les répertoires modifiables:
```sh
# Modifiable par tous et sans sticky bit
find / -type d \( -perm -0002 -a \ ! -perm -1000 \) -ls 2>/dev/null
# modifiables par tous et n'appartenant pas à root
find / -type d -perm -0002 -a \ ! -uid 0 -ls 2>/dev/null
# modifiables par tout le monde
find / -type f -perm -0002 -ls 2>/dev/null
```
### R41 - Sécurisation des accès pour les sockets et pipes nommées
Les `sockets` et `pipes` nommées doivent être protégées en accès par un répertoire possédant des droits appropriés. Les `sockets` locales ne doivent pas être créées à la racine d'un répertoire temporaire accessible à tous en écriture.
Les `sockets` autorisent la communication entre deux différents processus présents sur le même système ou bien une machine différente dans une architecture client-serveur.
Les `pipes` permettent de récupérer la sortie d'un programme et de l'insérer directement dans l'entrée d'un autre programme.
La commande `ss -xp` permet de lister l'ensemble des `sockets` et processus associés pour des `sockets` locales.
Les commandes suivantes permettent de lister les mémoires partagées et leurs droits d'accès des `sockets`:
```sh
# Liste des mémoires partagées
ipcs
# Liste de leurs droits d'accès
ls /dev/shm
```
La commande `lsof` permet d'obtenir des informations détaillées sur les entrées et sorties pour les processus du système.
### R43 - Durcissement et configuration du service syslog
Certains outils et services peuvent rapporter des éléments d'informations sur le système. Une grande partie de ceux-ci ne sont pas configurés de façon optimale à l'issue de l'installation du système. Les notes suivantes viennent en complément de la note technique ["Recommendation de sécurité pour la mise en oeuvre d'un système de journalisation"](https://www.ssi.gouv.fr/journalisation).
Syslog fait partie de ces services, il s'agit d'un système de journalisation composé de deux parties:
- serveur: collecte l'ensemble des messages systèmes au format syslog;
- plusieurs clients: envoient des messages au serveur, au travers de l'API syslog.
Plusieurs recommandations sont importantes à mettre en place pour une bonne configuration et un durcissement du service:
- R2: L'horodatage doit être activé pour l'ensemble des évènements pour une bonne exploitation des journaux;
- R3: L'horodatage doit être synchronisé sur plusieurs sources de temps internes;
- R4: Le dimensionnement de la partition de log doit être cohérente afin de conserver tous les journaux en local (estimation de l'espace disque nécessaire);
- R5: Export des logs sur une machine diffrente;
- R9: Si le contexte le permet, un transfert en temps réel des log est indispensable;
- R13: Contrôler la bande passante des fux réseau utilisé pour le transfert des logs;
- R16: Une partition doit être dédiée au logs;
- R20: L'accès aux logs doit être restreint aux utilisateurs ayant le besoin d'en connaître.
Pour la configuration de syslog, il est possible de modifier le fichier de configuration `/etc/syslog.conf`. Celui-ci permet de spécifier la priorité, la catégorie des messages et leur emplacement de sauvegarde.
Les prioritées syslog sont les suivantes:
- 0 => Urgence (emerg)
- 1 => Les alertes (alert)
- 2 => Critique (crit)
- 3 => Les erreurs (err)
- 4 => Avertissements (warn)
- 5 => Notification (notice)
- 6 => Informations (info)
- 7 => Débogage (debug)
Les catégories de messages syslog sont les suivantes:
- auth, authpriv, security => Authentification
- cron => Messages de l'ordonnanceur résident en mémoire
- daemon => Les messages des daemons
- kern => Les messages du noyau
- lpr => Messages de l'imprimante
- mail => Messages de Sendmail
- user => Messages des processus/application lancé par l'utilisateur
- local0 à local7 => est utilisé par les équipements Cisco et serveurs - Windows
- syslog => Messages du processus syslog
Dans le fichier de configuration de syslog, une entrée est de la forme suivante : `[category].[priority] [save_location]`
On pourrait par exemple journaliser les messages d'erreurs d'authentification dans un fichier `auth_error.log` en écrivant l'entrée suivante :
```sh
auth.err /var/log/auth_error.log
```
### R44 - Cloisonnement du service syslog par chroot
Quand les moyens techniques et sa configuration le permettent, le service syslog doit être enfermé dans un environnement chroot.
Sous système UNIX, `chroot`, pour "change root", est une commande permettant de changer le répertoire racine d'un processus. Elle permet d'en isoler son exécution dans un environnement limité afin d'éviter toute sorte de compromission.
### R46 - Journaux d'activité de service
Chaque service doit posséder un journal de log dédié sur le système. Ce fichier ne doit être accessible que par le serveur syslog, et ne doit pas être lisible, modifiable ou supprimable par le service directement.
On pourra donc éditer pour chaque service configuré le fichier `/etc/syslog.conf` avec le template explicité précédemment:
```sh
[category].[priority] [save_location]
```
L'objectif est qu'un service ne puisse pas manipuler ou accéder aux journaux d'un autre service. De plus, le service lui-même, en cas de compromission, ne puisse pas lire, effacer ou altérer ses journaux.
### R47 - Partition dédiée pour les journaux
Les journaux doivent reposer dans une partition séparée du reste du système.
Ceci permet d'éviter que le remplissage d'une partition entrave la collecte des journaux qui y sont stockés et reciproquement, une saturation due aux journaux viennent entraîner une indisponibilité de l'ensemble du système.
### R48 - Configuration du service local de messagerie
La messagerie est le second service couramment utilisé par le système pour informer des évolutions de son état. Suivant les distributions, il se peut que ce service soit mal configuré.
Quand il est installé sur la machine, le service doit être configuré pour accepté seulement:
- les mails à destination d'un utilisateur local à la machine;
- les connexions par la boucle locale (connexion distantes rejetées).
Un service léger comme ssmtp est à préférer dans la mesure du possible.
### R55 - Cage chroot et privilèges d'accès du service cloisonné
La cage `chroot` d'un service ne doit contenir que le strict minimum nécessaire à la bonne exécution de celui-ci. C'est-à-dire que le service doit posséder les privilèges d'un utilisateur simple (non root).
### R56 - Activation et utilisation de chroot par un service
`chroot` doit constament être utilisé sur le service s'il supporte ce mécanisme.
### R57 - Groupe dédié à l'usage de sudo
`sudo` est un utilitaire installé lorsqu'il y a un besoin de déléguer des droits et privilèges à certains utilisateurs. Il est donc important de se soucier de sa sécurité à deux niveau différents:
- au niveau du durcissement, afin d'éviter à un utilisateur malveillant de pouvoir exploiter les vulnérabilités du binaire;
- au niveau de sa configuration, où le fait de donner le droit à un utilisateur d'exécuter certaines commandes peut lui attribuer plus de privilèges et de prérogatives qu'initialement nécessaires.
Seul les utilisateurs du groupe sudo doivent avoir la permission de l'utiliser. Un groupe dédié à l'usage de sudo doit donc être créé.
On créé donc un groupe nommé `sudo_grp` avec la commande `groupadd`:
```sh
# Création du groupe
$ groupadd sudo_grp
# Ajout de l'utilisateur au groupe sudo_grp
$ gpasswd -a <username> sudo_grp
# Changement des droits et priorité
$ chgrp sudo_grp /usr/bin/sudo && chmod 4750 /usr/bin/sudo
$ ls -al /usr/bin/sudo
-rwsr-x--- 1 root sudo_grp 182600 Feb 27 2021 /usr/bin/sudo
```
### R58 - Directives de configuration sudo
Les directives ci-dessous doivent être activées par défaut dans le fichier de configuration `/etc/sudoers`.
| Directive | Description
|---------------------|-----------------------------------------------------
| noexec | appliquer le tag NOEXEC par défaut sur les command
| requiretty | imposer à l'utilisateur d'avoir un tty de login
| use_pty | utiliser un pseudo-tty lorsqu'une commande est exécu
| umask=0027 | forcer umask à un masque plus restrictif
| ignore_dot | ignorer le '.' dans $PATH
| env_reset | réinitialiser les variables d'environnement
| passwd_timeout=1 | allouer 1 minute pour entrer son mot de passe.
Ces directives sont traduites par les deux lignes suivantes, que l'on rajoute dans le fichier de configuration:
```sh
$ sudo EDITOR="vim" sudoedit /etc/sudoers
Defaults noexec,requiretty,use_pty,umask=0027
Defaults ignore_dot,env_reset,passwd_timeout=1
```
### R60 - Privilèges des utilisateurs cibles pour une commande sudo
Les utilisateurs cibles d'une règle doivent autant que possible être des utilisateurs non privilégiés (non root).
La configuration de l'utilisateur dans le fichier `/etc/sudoers` est la suivante, où "user" désigne l'utilisateur cible, celui dont les droits seront transférés pour les commandes spécifiées.
```sh
user ALL = (user) cmd1,cmd2, etc
%groupe ALL = (user) cmd1,cmd2, etc
```
### R62 - Du bon usage de la négation dans une spécification sudo
Les spécifications de commandes ne doivent pas faire intervenir de négation.
Exemple: `user ALL = ALL, !/bin/sh`
Cette approche par "blocklist" peut facilement être contournée. Il suffirait par exemple, dans le cas ci-dessus, de copier `/bin/sh` et le renommer afin de pouvoir l'exécuter.
### R63 - Arguments explicites dans les spécifications sudo
Toutes les commandes du fichier `sudoers` doivent préciser tous les arguments autorisés à être utilisés pour l'utilisateur. L'usage de wildcard "*" doit être évité autant que possible. L'absence d'argument pour une commande doit être spécifiée par la présence d'une chaîne vide ("").
### R64 - Du bon usage de sudoedit
L'édition d'un fichier par sudo doit être réalisé au travers de la commande `sudoedit`.
## Recommandations - Niveau Renforcé
### R3 - Principe de moindre privilège
Tout objet ou entité d'un système doit avoir les droits qui lui sont nécessaires et rien de plus. Avant de donner des droits à un service, exécutable ou encore un utilisateur il faut analyser ses besoins pour réduire ses droits au strict nécessaire. Sur debian cette séparation des droits repose en grande partie sur les 2 niveaux d'utilisateurs "classique" et root. La séparation entre ces 2 types d'utilisateur est primordiale pour éviter une escalade de privilège d'un utilisteur "classique" vers un utilisteur root.
### R6 - Cloisonnement des services réseau
Les services réseaux doivent être autant que possible hérbergés sur des environnements distincs pour éviter que la compromission d'un service en entraîne d'autres.
Il esxiste plusieurs solutions pour mettre en place ce cloisonnement :
* compte utilisateur dédié
* conteneurs spécifiques
* machine virtuelle ou physique
Chaque approche a ses avangtages et inconvénients. L'affectation d'un compte dédié par service est souvent moins efficace que l'isolation d'un service dans une machine virtuelle ou un conteneur mais demande moins d'efforts de mise en place. L'idéal étant d'avoir une machine physique dédiée pour chaque service mais cela demande beaucoup de ressources.
### R7 - Journalisation de l'activité des services
Pour pouvoir repérer une intrusion ou un disfonctionnement dans le système il faut que les activités du système et des services soivent journalisés. Ces journaux doivent être stockés en externe, non en local pour éviter une destruction ou une falcification de ces derniers en cas d'une compromission du système.
Chaque service doit avoir un journal dédié sur le système qui ne doit être accessible que par le serveur syslog et ne pas être modifiable par le service. Cela permet d'empêcher la modification par un service compromis de ses journaux ou de ceux d'un autre service.
### R13 - Restrictions d'accès sur le dossier /boot
Si possible la partition /boot ne doit pas être montée automatiquement et l'accès au dossier /boot doit être exclusivement réservé à l'utilisateur root.
### R16 - Dépôts de paquets durcis
Il est recommandé de toujours utilisé les dépôts les plus utilisants les recommandation les plus strictes disponibles pour la distribution concernée. Concernant Debian il est recommandé d'utiliser seulement les dépôts main, contrib et non-free qui sont déjà présents par défaut dans le fichier /etc/apt/sources.list.
### R17 - Mot de passe du chargeur de démarrage
Il est essentiel d'ajouter un mot de passe au chargeur de démarrage, car sans mot de passe un attaquant ayant un accès physique à la machine pourrait avoir les droits root dès le démarrage de la machine. Les chargeurs de démarrage GRUB et GRUB 2 offrent la possibilité d'ajouter un mot de passe au démarrage, ce qui n'est pas le cas de tous les systèmes. Ils sont donc recommandés pour un système GNU/Linux.
Pour ajouter un mot de passe au chargeur démarrage grub 2 sur debian la procédure est la suivante :
1. Génération d'un mot de passe chiffré avec la commande `grub-mkpasswd-pbkdf2`
```sh
grub-mkpasswd-pbkdf2
Enter password:
Reenter password:
PBKDF2 hash of your password is grub.pbkdf2.sha512.10000.7529F60E5A01F1BBB9958AD34B67032BABDEE16B30973FD8AEB83D0FB4F0A47EEDCEC92A60029C37213B1D43D8DEB7AA7C8E46ACB40DAC5F752326600C727838.3BD2E8A69778ED8269CACFEDCE765D2D179D721B3994909851517C6040946423D69E35D52D48D1C901C5AD8484DF6F7609E2F55B1E8AACD8BA04BCBDCC117E6E
```
2. Ajout du mot de passe dans le fichier de config `/etc/grub.d/40_custom`
```sh
# Password
set superusers="root"
password_pbkdf2 root grub.pbkdf2.sha512.10000.7529F60E5A01F1BBB9958AD34B67032BABDEE16B30973FD8AEB83D0FB4F0A47EEDCEC92A60029C37213B1D43D8DEB7AA7C8E46ACB40DAC5F752326600C727838.3BD2E8A69778ED8269CACFEDCE765D2D179D721B3994909851517C6040946423D69E35D52D48D1C901C5AD8484DF6F7609E2F55B1E8AACD8BA04BCBDCC117E6E
```
3. Recompilation de Grub2
On utilise la commande `grub-mkconfig` afin de recompiler et regénérer le fichier de config `/boot/grub/grub.cfg`.
```sh
# export du PATH pour avoir accès à la commande 'grub-mkconfig'
export PATH=$PATH:/usr/sbin
# Recompilation de grub
grub-mkconfig -o /boot/grub/grub.cfg
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.10.0-9-amd64
Found initrd image: /boot/initrd.img-5.10.0-9-amd64
Found linux image: /boot/vmlinuz-5.10.0-8-amd64
Found initrd image: /boot/initrd.img-5.10.0-8-amd64
done
```
4. Vérification de la recompilation
Afin de vérifier que la compilation s'est bien passé, on vérifie dans le fichier `/boot/grub/grub.cfg` que nos modifications sont bien inscrite.
```txt
### BEGIN /etc/grub.d/40_custom ###
# This file provides an easy way to add custom menu entries. Simply type the
# menu entries you want to add after this comment. Be careful not to change
# the 'exec tail' line above.
# Login/Password
set superusers = "root"
password_pbkdf2 root grub.pbkdf2.sha512.10000.7529F60E5A01F1BBB9958AD34B67032BABDEE16B30973FD8AEB83D0FB4F0A47EEDCEC92A60029C37213B1D43D8DEB7AA7C8E46ACB40DAC5F752326600C727838.3BD2E8A69778ED8269CACFEDCE765D2D179D721B3994909851517C6040946423D69E35D52D48D1C901C5AD8484DF6F7609E2F55B1E8AACD8BA04BCBDCC117E6E
### END /etc/grub.d/40_custom ###
```
Au prochain démarrage grub demandera un nom d'utilisteur (*root*) et le mot de passe avant de démarrer.
### R20 - Installation d'éléments secrets ou de confiance
L'installation d'éléments secrets ou de confiance (certificats racine, mots de passe de compte d'administration, clés publiques ...) doit se faire dès l'installation du système si possible ou sinon dès la fin de l'installation. Sur certaines distribution des secrets par défaut sont générés, il faut donc les modifier le plus rapidement possible. Dans le cas de débian les secrets doivent être entrés par l'utilisateur au cours de l'installation ce n'est donc pas un problème.
### R24 - Désactivation du chargement des modules noyau
La désactivation du chargement automatique des modules noyau est recommandée pour éviter le chargement de modules non utilisés qui pourraient être vulnérables ou exploitables par un attaquant.
Il existe 2 méthodes pour désactiver le chargement des modules noyau après le démarrage du système :
* commande non sauvegardée après redémarrage :
```
# sysctl -w kernel.modules_disabled=1
```
* modification du fichier de configuration */etc/systctl.conf* pour une persistence après redémarrage :
```
kernel.modules_disabled = 1
```
### R25 - Configuration sysctl du module Yama
*Yama* est un module de sécurité qui rassemble les protections de sécurité DAC du système qui ne sont pas gérées par le noyau. Il permet de rajouter une *sysctl* pour contrôler l'accès à *ptrace*. Cet appel système est critique car il permet de tracer le fonctionnement d'un processus. Il est donc recommandé de charger le module de sécurité Yama au démarrage du système et configurer la sysctl associée.
Pour activer le chargement module de sécurité Yama au démarrage il faut passer `CONFIG_SECURITY_YAMA` au kernel. On peut ensuite le gérer avec des sysctls dans `/proc/sys/kernel/yama`
Il existe 4 niveaux de sécurité de ptrace, il est recommandé d'utiliser au moins le niveau 1. Le niveau 1 limite la possibilité de faire appel à cet appel au processus parent. Pour cela on utilise la commande suivante :
```sh
# sysctl -w kernel.yama.ptrace_scope=1
```
### R26 - Désactivation des comptes utilisateurs inutilisés
Pour limiter les possibilités d'un attaquant qui viendrait à s'introduire sur le système, il est recommandé de désactiver les comptes utilisateurs qui ne sont pas utilisés. Les comptes de services n'ayant pas de raison de se connecter sont considérés comme des comptes inutilisés et doivent donc être désactivés.
Pour cela on utilise les commandes suivantes :
* Verrouillage d'un compte
```
usermod -L <compte>
```
* Désactivation de son shell de login
```
usrmod -s /bin/false <compte>
```
### R28 - Unicité et exclusivité des comptes de services
Les systèmes Linux utilisent des comptes de service pour isoler les applications et services les uns des autres et limiter les dégats de la compromission d'un service. Pour cela il faut veiller à ce que chaque service ait un compte dédier avec les seulement les permissions qui lui sont nécessaires.
### R29 - Délai d'expiration de sessions utilisateurs
La plupart des administrateurs et utilisateurs ouvrent des connexions distantes vers les systèmes qu'ils maintiennent et exploitent, mais peuvent oublier de fermer ces sessions. Ceci expose inutilement l'hôte à des risques de compromissions (réutilisation d'un accès déjà ouvert à partir d'un compte compromis, vol de session, etc ...), en plus de consommer inutilement des ressources.
Cette fonctionnalité est souvent présente sous la forme d'expiration de session après inactivité (*idle timeout* en anglais). Certains shells (bash, ksh, zsh) offrent une variable d'environnement *TMOUT* quiindique en secondes le délai maximum d'inactivité pour une session shell donnée.
Pour appliquer ce paramètre à tous les utilisateurs, il faut aller configurer le fichier `/etc/bash.bashrc` et ajouter la ligne suivante :
```
#Fermeture de la session après 10 min d'inactivité
export TMOUT = 600
```
Puis on utilise la commande suivante afin de mettre à jours les bash :
```
source /etc/bash.bashrc
```
### R35 - Valeur de umask
Le umask système doit être positionné à 0027 (par défaut, tout fichier créé n'est lisible que par l'utilisateur et son groupe, et modifiable que par son propriétaire). Le umask pour les utilisateurs doit être positionné à 0077 (tout fichier créé par un utilisateur n'est lisible et modifiable que par lui).
Sur Debian le umask système peut être directement modifié dans `/etc/init.d/rc` et celui des utilisateurs via `/etc/login.defs`.
Il suffit de modifier la ligne suivante :
```
UMASK <valeur du umask>
```
### R38 - Exécutables setuid root
Les exécutables *setuid* doivent être le moins nombreux possible. Lorsque que seuls les administrateurs doivent les exécuter, il faut leur retirer le *bitset-uid* et leur préférer des commandes comme *su* ou *sudo*, qui peuvent être surveillées.
La commande suivante permet de lister tous les fichiers setuid/setgid :
```
find / -type f -perm /6000 -ls 2>/dev/null
```
On utilise ensuite la commande chmod pour retirer le setuid/setgid :
```
# retire le setuid
chmod u-s <fichier>
# retire le setgid
chmod g-s <fichier>
```
### R50 - Journalisation de l'activité par auditd
Il est recommandé de journaliser l'activité des services et du système à l'aide d'auditd. Les journaux créés par auditd étant verbeux surtout quand de nombreuses activités sont raportées. L'outilaureportpermet de sélectionner les informations intéressantes enfonction de critères bien spécifiques : contexte sur des échecs d'authentification, rapport d'évènement sur certains fichiers ou répertoires, évènements anormaux (crash de programmes, reconfiguration de cartes réseaux).
### R53 - Restriction des accès des services déployés
Les services déployés doivent voir leurs accès au système limités au strict nécessaire, notamment au niveau fichiers, processus ou réseau. Plusieurs solutions de cloisonement existent proposant différents niveaux d'abstraction :
* par conteneurs
* par émulation
* par hyperviseur léger *bare-metal*
* par hyperviseur noyau
### R54 - Durcissement des composants de virtualisation
Il est recommandé de durcir tout composant de virtualisation, notament par l'application de mesures techniques contrant les techniques d'exploitation.
### R61 - Limitation du nombre de commandes nécessitant l'option EXEC
Les commandes nécessitant l'exécution de sous-processus (tagEXEC) doivent être explicitement listées et réduites autant que possible au strict minimum. Les commandes ayant nécessitant l'option exec sont un grand risque d'élévation de privilège par un attaquant s'il arrive à lancer une de ces commandes avec sudo.
## Recommandations - Niveau Elevé
### R4 - Utilisation des fonctionnalités de contrôle d'accès
Il est recommandé d'utiliser les fonctionnalités de contrôle d'accès obligatoire (MAC) en plus du traditionnel modèle utilisateur Unix (DAC), voire éventuellement de les combiner avec des mécanismes de cloisonnement. Il existe différents systèmes de cloisonnement qui ont chacun leurs avantages et leurs inconvennients.
### R11 - Directive de configuration de l'IOMMU
Le service d'IOMMU doit être activé lorsque l'architecture matérielle le supporte.
Dans le cadre de l'exploitation de systèmes virtualisés, le service IOMMU, géré directement par le noyau, permet de protéger la mémoire contre accès non contrôlés. Il est recommandé de forcer son activation en passant une option supplémentaire lors du démarrage du noyau Linux.
L'activation peut être forcée au travers du fichier de configuration `/etc/default/grub` en ajoutant le paramètre suivant:
```sh
GRUB_CMDLINE_LINUX="... iommu=force"
```
Google Drive
Gist
Clipboard
Sign in with Wallet
