# Recommandtion de niveau intermédiaire

## Point de depart du niveau intermediraire :


## Configurer le BIOS/UEFI

Redémarrez votre ordinateur : Assurez-vous que votre ordinateur est complètement éteint, puis redémarrez-le.

Appuyez sur la touche appropriée : Pendant le processus de démarrage, avant que le système d'exploitation ne commence à charger, appuyez sur la touche spécifique pour accéder au **BIOS/UEFI**. Cette touche varie selon le fabricant, mais elle est souvent `Del, F2, F10, F12, ou Esc.` La plupart des ordinateurs affichent brièvement un message à l'écran indiquant quelle touche appuyer.

1. **Configurer le BIOS/UEFI :**
Les options disponibles dans le **BIOS/UEFI peuvent varier**, mais voici quelques paramètres courants que vous pourriez ajuster :

1. **Ordre de démarrage (Boot Order) :** Vous pouvez spécifier l'ordre dans lequel le système cherche à démarrer à partir des différents périphériques (disque dur, lecteur DVD, clé USB, etc.). **Assurez-vous que le périphérique de démarrage principal est correctement configuré**.

1. **Horloge système (System Clock) :** Vérifiez que l'heure et la date sont correctes.

1. **Activer ou désactiver des fonctionnalités matérielles :** Le BIOS/UEFI peut avoir des options pour activer ou désactiver certaines fonctionnalités matérielles, telles que la virtualisation, la gestion d'alimentation avancée, etc.

1. **Mot de passe du BIOS/UEFI :** Définissez un mot de passe du BIOS/UEFI pour empêcher l'accès non autorisé aux paramètres du BIOS. Assurez-vous de choisir un mot de passe fort.

1. **Désactiver les ports inutilisés :** Désactivez les ports matériels (USB, ports PCI, etc.) qui ne sont pas utilisés pour réduire les surfaces d'attaque potentielles.

1. **Configurer la vérification de l'intégrité du démarrage (Secure Boot) :** Activez Secure Boot pour empêcher le démarrage de systèmes d'exploitation non signés. Cependant, assurez-vous que votre système d'exploitation prend en charge Secure Boot.

1. **Vérifier les mises à jour du BIOS/UEFI :** Assurez-vous d'avoir la dernière version du BIOS/UEFI installée, car les mises à jour peuvent inclure des corrections de sécurité importantes contre certaine CVE physique.

1. **Configurer le mot de passe de démarrage :** Généralement, vous trouverez une option appelée "Set Supervisor Password" ou quelque chose de similaire. Sélectionnez cette option et suivez les instructions pour définir un mot de passe fort.

## Activer le démarrage sécurisé UEFI

Activer le démarrage sécurisé UEFI (Secure Boot) est une mesure de sécurité mise en place dans les BIOS UEFI (Unified Extensible Firmware Interface) des ordinateurs modernes. Voici une explication de son utilité :

* Protection contre les logiciels malveillants au démarrage :
L'objectif principal du Secure Boot est de garantir que le système d'exploitation (OS) qui démarre sur l'ordinateur est signé numériquement par une clé de confiance. Cela aide à prévenir le démarrage de logiciels malveillants tels que les rootkits et les bootkits, qui pourraient compromettre la sécurité du système dès le démarrage.

* Intégrité du chargement du système d'exploitation :
Le Secure Boot assure l'intégrité de la chaîne de confiance du démarrage en vérifiant les signatures numériques des composants du démarrage, tels que le chargeur d'amorçage (bootloader) et le noyau du système d'exploitation. Si une modification non autorisée est détectée, le démarrage est bloqué.

* Protection contre les attaques de type "evil maid" :
Secure Boot aide à protéger l'ordinateur contre les attaques physiques, notamment celles où un attaquant tente de remplacer ou de compromettre le chargeur d'amorçage ou le noyau lorsqu'il a un accès physique à l'ordinateur, par exemple, en utilisant une clé USB ou en modifiant le disque dur.

* Réduction des risques de piratage :
En empêchant le démarrage de systèmes d'exploitation non signés, Secure Boot contribue à réduire les risques de piratage et renforce la sécurité globale du système.

### Génération des clés

#Création d'un répertoire de travail : mkdir efikeys
#Changement dans le répertoire de travail : cd efikeys
#Génération des clés avec OpenSSL :

openssl req -new -x509 -newkey rsa:2048 -subj "/CN=PK-Debian/" -keyout PK.key -out PK.crt -days 3650 -nodes -sha256
openssl req -new -x509 -newkey rsa:2048 -subj "/CN=KEK-Debian/" -keyout KEK.key -out KEK.crt -days 3650 -nodes -sha256
openssl req -new -x509 -newkey rsa:2048 -subj "/CN=Kernel-SignKey-Debian/" -keyout db.key -out db.crt -days 3650 -nodes -sha256

### Préparation et installation des clés

##### Génération de la liste de signatures pour chaque clé :

cert-to-efi-sig-list -g "$(uuidgen)" PK.crt PK.esl
sign-efi-sig-list -k PK.key -c PK.crt PK.esl PK.auth

cert-to-efi-sig-list -g "$(uuidgen)" KEK.crt KEK.esl
sign-efi-sig-list -a -k PK.key -c PK.crt KEK KEK.esl KEK.auth

cert-to-efi-sig-list -g "$(uuidgen)" db.crt db.esl
sign-efi-sig-list -a -k KEK.key -c KEK.crt db db.esl db.auth

### Signature du binaire de démarrage

##### Utilisation de sbsign pour signer le binaire :

sbsign --key KEK.key --cert KEK.crt --output BootSigned.efi Boot.efi

### Signature des modules DKMS

##### Création d'une paire de clés privée/publique pour DKMS :

mkdir -p /etc/dkms/keys
chmod -R 700 /etc/dkms/keys
cd /etc/dkms/keys
openssl req -new -x509 -newkey rsa:2048 -keyout MOK.key -out MOK.crt -nodes -days 3650 -subj "/CN=Srv01/"
openssl x509 -in MOK.crt -out MOK.der -outform DER

##### Importation de la clé publique dans la base MOK :

mokutil --import /etc/dkms/keys/MOK.der

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

Configurer un mot de passe pour le chargeur de démarrage GRUB sur Debian offre une couche supplémentaire de sécurité en empêchant l'accès non autorisé aux options avancées du système au moment du démarrage. Voici quelques raisons pour lesquelles cela peut être utile :

* Protection contre les modifications de configuration : En configurant un mot de passe pour GRUB, vous empêchez quiconque d'apporter des modifications à la configuration du chargeur de démarrage ou aux options de démarrage avancées sans fournir le mot de passe correct.

* Sécurisation de Single User Mode : Si quelqu'un a un accès physique à votre machine et peut démarrer en mode utilisateur unique (single user mode), il peut potentiellement contourner les mots de passe du système. En configurant un mot de passe GRUB, vous renforcez la sécurité même dans ce mode.

* Protection contre le changement de mot de passe root : Un utilisateur malveillant pourrait essayer de changer le mot de passe root au démarrage. Avec un mot de passe GRUB, cette tentative serait bloquée sans le mot de passe approprié.

* Empêcher le démarrage de systèmes non autorisés : Si votre ordinateur a plusieurs systèmes d'exploitation installés en multi-amorçage, un mot de passe GRUB empêche le démarrage de systèmes non autorisés.

* Confidentialité des paramètres du noyau : Certains paramètres de noyau peuvent être modifiés au démarrage en utilisant GRUB. Un mot de passe GRUB garantit que ces paramètres ne peuvent être modifiés que par des utilisateurs autorisés.

##### Nous avons implémenté cette fonction avec un script :
#!/bin/bash

# Installer le paquet grub2
apt-get install -y grub2

# Générer un mot de passe pour GRUB
grub_password=$(grub-mkpasswd-pbkdf2)

# Copier le mot de passe généré pour une utilisation ultérieure
echo "Mot de passe GRUB généré :"
echo "$grub_password"

# Configurer le fichier GRUB
grub_file="/etc/default/grub"
grub_backup="$grub_file.backup"
cp "$grub_file" "$grub_backup"

# Ajouter GRUB_ENABLE_CRYPTODISK
sed -i '/^GRUB_CMDLINE_LINUX=/s/"$/ GRUB_ENABLE_CRYPTODISK=y"/' "$grub_file"

# Ajouter GRUB_PASSWORD
echo "GRUB_PASSWORD=$grub_password" >> "$grub_file"

# Mettre à jour GRUB
update-grub

## Paramétrer les options de configuration de la mémoire

Nous allons reprendre notre service postgresql et allons lui allouer des ressources. Nous le faisons via un script pour simplifier les choses, cependant c'est possible de la faire manuellement dans le fichier de conf du paquet.

#!/bin/bash

# Chemin vers le fichier de configuration PostgreSQL
PG_CONF="/etc/postgresql/15/main/postgresql.conf"

# Paramètres de configuration de la mémoire
SHARED_BUFFERS="512MB"
EFFECTIVE_CACHE_SIZE="1GB"
WORK_MEM="32MB"
MAINTENANCE_WORK_MEM="128MB"

# Sauvegarder une copie du fichier de configuration d'origine
cp $PG_CONF $PG_CONF.backup

# Modifier les paramètres de configuration de la mémoire
sudo sed -i "s/^#*shared_buffers.*/shared_buffers = $SHARED_BUFFERS/" $PG_CONF
sudo sed -i "s/^#*effective_cache_size.*/effective_cache_size = $EFFECTIVE_CACHE_SIZE/" $PG_CONF
sudo sed -i "s/^#*work_mem.*/work_mem = $WORK_MEM/" $PG_CONF
sudo sed -i "s/^#*maintenance_work_mem.*/maintenance_work_mem = $MAINTENANCE_WORK_MEM/" $PG_CONF

sudo service postgresql restart

## Paramétrer les options de configuration du noyau
Ouvrir le fichier de configuration sysctl :

sudo nano /etc/sysctl.conf

Ajoutez les options de configuration recommandées par l'ANSSI au **fichier sysctl.conf**.

# Restreint l'accès au buffer dmesg
kernel.dmesg_restrict=1

# Cache les adresses noyau dans /proc et les différentes autres interfaces
kernel.kptr_restrict=2

# Spécifie explicitement l'espace d'identifiants de processus supporté par le noyau
kernel.pid_max=65536

# Restreint l'utilisation du sous-système perf
kernel.perf_cpu_time_max_percent=1
kernel.perf_event_max_sample_rate=1
kernel.perf_event_paranoid=2

# Active l'ASLR
kernel.randomize_va_space=2

# Désactive les combinaisons de touches magiques (Magic System Request Key)
kernel.sysrq=0

# Restreint l'usage du BPF noyau aux utilisateurs privilégiés
kernel.unprivileged_bpf_disabled=1

Pour appliquer les changements immédiatement, exécutez la commande suivante

sudo sysctl -p

Vous pouvez vérifier si les options sont correctement appliquées en utilisant la commande suivante :

sysctl -a | grep 'dmesg_restrict\|kptr_restrict\|pid_max\|perf_cpu_time_max_percent\|perf_event_max_sample_rate\|perf_event_paranoid\|randomize_va_space\|sysrq\|unprivileged_bpf_disabled'

**Résultat :**

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

## Activer et configurer le LSM Yama

Le LSM (Linux Security Module) Yama est un module de sécurité pour le noyau Linux qui met en œuvre plusieurs fonctionnalités pour renforcer la sécurité du système.

Nous allons installer le paquet AppArmor et le configurer :

sudo apt-get install apparmor
sudo nano /etc/default/grub


sudo update-grub


On voit le "1" apparaitre ce qui signifie que le LSM Yama est bien activé.

## Paramétrer les options de configuration du réseau IPv4
Ouvrir le fichier de configuration du noyau :

sudo nano /etc/default/grub

Recherchez la ligne qui commence par **GRUB_CMDLINE_LINUX** dans le fichier de configuration. Cette ligne est utilisée pour définir les options de ligne de commande du noyau.

Ajouter les options de compilation du noyau :

GRUB_CMDLINE_LINUX="net.ipv4.tcp_syncookies=1"

Cela désactive active les cookies SYN pour prévenir les attaques de type SYN flood

Après avoir modifié le fichier de configuration, enregistrez les modifications et fermez l'éditeur de texte. Ensuite, mettez à jour GRUB pour appliquer les changements :

sudo update-grub

Après avoir redémarer la machine, vous pouvez vérifier si les options sont correctement appliquées en utilisant la commande suivante :

sysctl -a | grep 'syncookies'

Vous devriez voir des résultats indiquant que les cookies SYN sont activés **(net.ipv4.tcp_syncookies=1)**.
## Désactiver le plan IPv6

sudo nano /etc/sysctl.conf

Ajoutez les lignes suivantes à la fin du fichier pour désactiver IPv6.

# Désactiver IPv6
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1

Enregistrez les modifications et quittez l'éditeur.
Rechargez les paramètres du noyau pour appliquer les modifications.

sudo sysctl -p

## Paramétrer les options de configuration des systèmes de fichiers

La configuration des options de systèmes de fichiers sur Linux se fait généralement dans le fichier /etc/fstab. Ce fichier contient des informations sur les systèmes de fichiers et les points de montage.

## Partitionnement type
Pour ce parti nous allons appliquer les recommandations de l'ANSSI. Nous allons partitionner le systeme comme suit :


Nous allons mettre des captures d'écrans du paramétrage de 2 partitions. Le procédé et les mêmes pour les autres.

##### Partitionnage manuel :

##### Parametrage de /boot :

##### Parametrage de /opt :

Une fois la configuration de toutes les partitions faites, nous appliquer les chagements.

## Éxpirer les sessions utilisateur locales
Pour configurer l'expiration des sessions utilisateur locales sur Debian nous allons utiliser **chage**. Cet outil permet de configurer les **paramètres d'expiration des comptes d'utilisateurs**, y compris la **durée de validité du mot de passe** et la **durée de vie du compte**.

sudo chage --expiredate 2024-01-01 user

Pour vérifier les modifications :

sudo chage -l user

## Assurer l’imputabilité des actions d’administration

#Désactiver un compte de service
sudo passwd --lock nom_dutilisateur

#Optionnel : masquer le compte de la liste de connexion (en ajoutant un ! devant le nom d'utilisateur)
sudo usermod --expiredate 1 --shell /usr/sbin/nologin nom_dutilisateur

## Désactiver les comptes de service

Pour voir les comptes sur la machine on peut afficher le contenu du fichier shadow :

cat /etc/shadow


Pour mettre une date d'expiration sur le compte "service_account" on peut faire cela :

usermod --expiredate 1 service_account

Ce qui fixera l'expiration du compte à 1 jour.

## Utiliser des comptes de service uniques et exclusifs
#!/bin/bash

# Liste des services et de leurs utilisateurs associés
declare -A services=(
["webserver"]="www-data"
["database"]="mysql"
["mailer"]="postfix"
["dns"]="bind"
# Ajoutez d'autres services au besoin
)

# Parcourir la liste des services
for service in "${!services[@]}"; do
user="${services[$service]}"

# Vérifier si l'utilisateur existe déjà
if id "$user" &>/dev/null; then
echo "L'utilisateur $user existe déjà."
else
# Créer un nouvel utilisateur pour le service
sudo adduser --system --no-create-home --group "$user"
echo "L'utilisateur $user a été créé."

# Ajouter l'utilisateur au groupe du service s'il existe
if id "$service" &>/dev/null; then
sudo usermod -aG "$service" "$user"
echo "L'utilisateur $user a été ajouté au groupe $service."
fi
fi
done

Cela va creer un utilisateur pour chaque service indiquer dans le script. On peut le verifier dans /etc/shadow


## Modifier les directives de configuration sudo
Le but de cette mesure est de limiter l'accès à la commande sudo pour réduire le risque d'utilisation malveillante ou accidentelle des privilèges élevés mais également d'assurer que toutes les commandes exécutées avec sudo soient correctement journalisées.

Première étapes est de modifier la configuration du fichier /etc/sudoers :
* **Configuration de base du fichier**

#
# This file MUST be edited with the 'visudo' command as root.
#
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
#
# See the man page for details on how to write a sudoers file.
#
Defaults        env_reset
Defaults        mail_badpass
Defaults        secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

# This fixes CVE-2005-4890 and possibly breaks some versions of kdesu
# (#1011624, https://bugs.kde.org/show_bug.cgi?id=452532)
Defaults        use_pty

# This preserves proxy settings from user environments of root
# equivalent users (group sudo)
#Defaults:%sudo env_keep += "http_proxy https_proxy ftp_proxy all_proxy no_proxy"

# This allows running arbitrary commands, but so does ALL, and it means
# different sudoers have their choice of editor respected.
#Defaults:%sudo env_keep += "EDITOR"

# Completely harmless preservation of a user preference.
#Defaults:%sudo env_keep += "GREP_COLOR"

# While you shouldn't normally run git as root, you need to with etckeeper
#Defaults:%sudo env_keep += "GIT_AUTHOR_* GIT_COMMITTER_*"

# Per-user preferences; root won't have sensible values for them.
#Defaults:%sudo env_keep += "EMAIL DEBEMAIL DEBFULLNAME"

# "sudo scp" or "sudo rsync" should be able to use your SSH agent.
#Defaults:%sudo env_keep += "SSH_AGENT_PID SSH_AUTH_SOCK"

# Ditto for GPG agent
#Defaults:%sudo env_keep += "GPG_AGENT_INFO"

# Host alias specification

# User alias specification

# Cmnd alias specification

# User privilege specification
root    ALL=(ALL:ALL) ALL

# Allow members of group sudo to execute any command
%sudo   ALL=(ALL:ALL) ALL

# See sudoers(5) for more information on "@include" directives:

@includedir /etc/sudoers.d

Les directives à mettre en place dans le fichier de configuration pour améliorer la sécurité :
* **Configurer la journalisation**

Dans un premier temps créer un fichier sudo.log dans /var/log/ qui va accueillir l'ensembles des logs liée à l'utilisation de SUDO.

Ensuite il faut rajouter la directive suivant dans le fichier de configuration /etc/sudoers :

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

Avec l'ajout de cette directive, les actions effectuées avec la commande sudo seront journalisées.

* **Délai de grâce pour la ré-authentification**

La mise en place d'un délai de grâce va permettre de réduire le délai avant de réeffectué une demande de mot de passe pour avoir de nouveau les droits privilègié.

Defaults timestamp_timeout=X #où X est le nombre de minutes.

* **Restreindre ls chemins d'exécution**

Cette diretive permet de réduire les chemins d'exécutions de la commande SUDO en excluant les chemins "/home" et "/tmp" ce qui réduire les avus de chemins d'exécution.

Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

* **Sécurité des TTY**

L'utilisation de la directive requiretty va permettre prévenir l'exécution de commandes 'sudo' à partir de scripts automatisés non interatifs. Cela réduit les risques d'exploitation de faille de sécurité par des scripts automatisées ou des utilisateurs malveillants qui ne possèdent pas un accès direct à un terminal interactif.

Defaults requiretty

* **Désactivé la préservation de l'environnement**

Cette mesure prévient les situations où des variables d'environnement personnalisées ou manipulées pourraient influencer le comportement des commandes exécutées avec des privilèges élevés, réduisant ainsi les risques d'exploitations malveillantes basées sur l'environnement.

Defaults env_reset

**Configuration finale du fichier** :

#
# This file MUST be edited with the 'visudo' command as root.
#
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
#
# See the man page for details on how to write a sudoers file.
#
Defaults        env_reset
Defaults        mail_badpass
Defaults        secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

# This fixes CVE-2005-4890 and possibly breaks some versions of kdesu
# (#1011624, https://bugs.kde.org/show_bug.cgi?id=452532)
Defaults        use_pty

# This preserves proxy settings from user environments of root
# equivalent users (group sudo)
#Defaults:%sudo env_keep += "http_proxy https_proxy ftp_proxy all_proxy no_proxy"

# This allows running arbitrary commands, but so does ALL, and it means
# different sudoers have their choice of editor respected.
#Defaults:%sudo env_keep += "EDITOR"

# Completely harmless preservation of a user preference.
#Defaults:%sudo env_keep += "GREP_COLOR"

# While you shouldn't normally run git as root, you need to with etckeeper
#Defaults:%sudo env_keep += "GIT_AUTHOR_* GIT_COMMITTER_*"

# Per-user preferences; root won't have sensible values for them.
#Defaults:%sudo env_keep += "EMAIL DEBEMAIL DEBFULLNAME"

# "sudo scp" or "sudo rsync" should be able to use your SSH agent.
#Defaults:%sudo env_keep += "SSH_AGENT_PID SSH_AUTH_SOCK"

# Ditto for GPG agent
#Defaults:%sudo env_keep += "GPG_AGENT_INFO"

# Host alias specification

# User alias specification

# Cmnd alias specification

# User privilege specification
root    ALL=(ALL:ALL) ALL

# Allow members of group sudo to execute any command
%sudo   ALL=(ALL:ALL) ALL

# Log file
Defaults        logfile="/var/log/sudo.log"

#Timeout beforce re-authentification
Defaults        timestamp_timeout=5

# TTY security
Defaults        requiretty


# See sudoers(5) for more information on "@include" directives:

@includedir /etc/sudoers.d

## Utiliser des utilisateurs cibles non-privilégiés pour les commandes sudo

Lorsque vous utilisez sudo, vous pouvez spécifier un utilisateur cible non-privilégié pour exécuter une commande avec des privilèges élevés. Cela permet de limiter les risques associés à l'exécution de certaines commandes en permettant à des utilisateurs spécifiques d'exécuter des commandes précises avec des privilèges root, sans leur donner un accès complet en tant que superutilisateur.

La syntaxe générale de la commande sudo pour exécuter une commande en tant qu'un autre utilisateur est la suivante :

sudo -u <USER> commande
sudo -u thomas ufw allow ssh

Si on souhaite donner à un utilisateur spécifique des droits sudo pour exécuter n'importe quelle commande en tant qu'un autre utilisateur, on ajoute une règle spécifique dans le fichier /etc/sudoers en utilisant la commande visudo (qui garantit la syntaxe correcte du fichier sudoers) :

sudo visudo

thomas ALL=(ALL:ALL) ALL

## Bannir les négations dans les spécifications sudo

Le but de cette mesure est d'améliorer la clarté et la sécurité des configurations de privilèges. Cela permet de réduire les risques d'erreurs de configuration et facilite l'audit et la compréhension des permissions accordées, en s'assurant que les règles de privilèges soient explicites, directes et sans ambiguïté.

Pour la mise en place de cette mesure, il faut :

* Identifier les négations dans le fichier de configuration de sudo

Vérifier que dans le fichier /etc/sudoers aucune négation n'est présente (Par exemple `! /usr/bin/vim`). Si c'est le cas, il faudra impérativement la remplacer par une règle positive

* Remplacer les négations par des règles positives

Pour éviter d'utiliser des négations, on peut définir explicitement ce que les utilisateurs sont autorisés à faire.

Par exemple, au lieu de dire "un utilisateur peut exécuter toutes les commandes sauf `/usr/bin/vim`", spécifiez les commandes qu'il peut exécuter."

* Utilisation de Groupes et d'Alias

Pour gérer efficacement les permissions avec clarté, vous pouvez définir des groupes et des alias de commandes dans le fichier sudoers.

Par exemple, au lieu d'attribuer individuellement chaque commande de mise à jour, créez un alias `Cmnd_Alias UPDATE_CMDS = /usr/bin/apt-get update, /usr/bin/apt-get upgrade.`

Ensuite, accordez l'accès à cet alias à un groupe d'utilisateurs, comme `%admins ALL=(ALL) NOPASSWD: UPDATE_CMDS`, ce qui permet aux membres du groupe admins d'exécuter ces commandes de mise à jour sans nécessiter de mot de passe.

## Préciser les arguments dans les spécifications sudo 43
Ouvrir le fichier de configuration sudoers :

sudo visudo

**Ajouter des spécifications sudo en précisant les arguments :**

user ALL = /bin/dmesg ""

Cela indique que l'utilisateur "user" peut exécuter la commande /bin/dmesg sans argument spécifié

**Éviter l'utilisation de * (wildcard) autant que possible :**

L'utilisation de * dans les règles sudo devrait être évitée autant que possible. Par exemple, au lieu d'utiliser une règle générique comme :

user ALL = /usr/bin/*

**sudoedit pour éditer des fichiers de manière sécurisée :**

Si vous avez besoin de permettre à un utilisateur d'éditer des fichiers en utilisant un éditeur de texte, préférez l'utilisation de sudoedit pour éviter les risques associés à certains éditeurs.

user ALL = sudoedit /chemin/vers/fichier

Cela permet à l'utilisateur "user" d'utiliser sudoedit pour éditer le fichier spécifié.

**Enregistrez les modifications et quittez**

**Remarque :** Assurez-vous de bien tester les modifications avant de quitter l'éditeur pour éviter de vous retrouver avec un sudoers inaccessible.
## Éditer les fichiers de manière sécurisée avec sudo

Il est important d'utiliser sudo pour éditer les fichiers de configuration système, car cela garantit que vous avez les permissions nécessaires pour effectuer des modifications.

Ouvrez le fichier avec sudo et nano :

sudo nano /chemin/du/fichier

Faites vos modifications dans l'éditeur nano.

* Après avoir effectué vos modifications, appuyez sur Ctrl + X pour quitter nano.

* Vous serez invité à sauvegarder les modifications. Appuyez sur Y pour confirmer, puis appuyez sur Entrée pour confirmer le nom du fichier.

Ouvrez le fichier avec sudo et vim :

sudo vim /chemin/du/fichier

* Appuyez sur i pour entrer en mode insertion.

* Faites vos modifications dans vim.

* Après avoir effectué vos modifications, appuyez sur Esc pour quitter le mode insertion.

* Tapez :wq et appuyez sur Entrée pour sauvegarder et quitter vim.

## Restreindre les droits d’accès aux fichiers et aux répertoires sensibles

# Autoriser l'accès uniquement à l'utilisateur root pour /etc/shadow
sudo chown root:root /etc/shadow
sudo chmod 600 /etc/shadow

# Autoriser l'accès uniquement à l'utilisateur root pour /etc/passwd
sudo chown root:root /etc/passwd
sudo chmod 644 /etc/passwd

## Restreindre les accès aux sockets et aux pipes nommées

La restriction des accès aux sockets et aux pipes nommées (named pipes) sur Debian peut être réalisée en utilisant les permissions appropriées ainsi que les mécanismes de contrôle d'accès disponibles dans le système d'exploitation.

##### Nous allons le faire pour le service postgresql :

On ouvre le fichier de conf postgresql.conf, pour trouver ou est stocker le socket.


On voit qu'il est stocker dans : /var/run/postgresql

Nous allons donc lui attribuer les bon droits :

chmod 600 /var/run/postgresql/

On restart le service pour que les changements soit pris en compte :

systemctl restart postgresql

## Séparer les répertoires temporaires des utilisateurs
**1.Créer des répertoires temporaires utilisateur :** Créez un répertoire temporaire pour chaque utilisateur. Vous pouvez le faire dans le répertoire /tmp ou dans un autre emplacement selon vos besoins.

sudo mkdir /tmp/user_tmp

Assurez-vous de définir les autorisations appropriées pour que chaque utilisateur puisse accéder à son propre répertoire temporaire :

sudo chmod 1777 /tmp/user_tmp

La permission 1777 garantit que tous les utilisateurs peuvent écrire dans le répertoire, mais ils ne peuvent supprimer que leurs propres fichiers.

1. **Configurer PAM pour créer automatiquement les répertoires temporaires :** Modifiez le fichier de configuration PAM pour que les répertoires temporaires soient automatiquement créés lorsqu'un utilisateur se connecte. Ouvrez le fichier /etc/pam.d/common-session avec un éditeur de texte :

sudo nano /etc/pam.d/common-session

Ajoutez la ligne suivante à la fin du fichier :

session required pam_mkhomedir.so

Cette ligne indique à PAM de créer automatiquement le répertoire utilisateur s'il n'existe pas lorsqu'un utilisateur se connecte.

Pour que les modifications apportées à PAM prennent effet, redémarrez le service d'authentification. Sur Debian, cela peut être fait avec la commande suivante :

sudo systemctl restart systemd-logind

## Désactiver les fonctionnalités des services non essentielles

#!/bin/bash

# Désactiver les fonctionnalités des services non essentielles

# Désactiver le service cups (impression) s'il n'est pas nécessaire
sudo systemctl disable cups

# Désactiver le service avahi (découverte de services) s'il n'est pas nécessaire
sudo systemctl disable avahi-daemon

# Désactiver le service bluetooth s'il n'est pas nécessaire
sudo systemctl disable bluetooth

# Désactiver le service rpcbind (NFS) s'il n'est pas nécessaire
sudo systemctl disable rpcbind

# Désactiver le service cups-browsed (découverte automatique des imprimantes) s'il n'est pas nécessaire
sudo systemctl disable cups-browsed

# Désactiver le service iscsi (stockage sur réseau) s'il n'est pas nécessaire
sudo systemctl disable iscsid

# Désactiver le service speech-dispatcher (support de synthèse vocale) s'il n'est pas nécessaire
sudo systemctl disable speech-dispatcher

## Configurer les privilèges des services

Nus allons configurer les privilèges sur certains répertoires liés à PostgreSQL en définissant des permissions restrictives, on ajoute l'utilisateur au groupe PostgreSQL. Ces actions visent à renforcer la sécurité en limitant l'accès aux ressources sensibles de PostgreSQL (Fichiers de conf).

##### Ajoute l'utilisateur actuel au groupe PostgreSQL
sudo usermod -aG postgres thomas

##### Définit les permissions sur le répertoire principal de PostgreSQL
sudo chmod 700 /var/lib/postgresql/15/main

##### Définit les permissions sur le répertoire de la base de données PostgreSQL
sudo chmod 700 /var/lib/postgresql/15/main/base

##### chmod 700 :
C'est un code de permission numérique. En octal, cela signifie que le propriétaire a la permission de lecture (4), écriture (2) et exécution (1), tandis que les autres (groupes et autres utilisateurs) n'ont aucune permission (0).

## Cloisonner les services

Dans ce parti nous avons choisi de segmenter le réseau avec des règles IPTABLES.

En effet pour notre service Postgresql, nous autorisons qu'une seule adresse IP à se connecter à ce service, le trafic en input et output n'ait autorisé que pour cette IP, tous les trafics qui sont different et DROP. Le trafic qui est different de celui-ci sera DROP.

# Définir l'adresse IP autorisée à accéder à PostgreSQL
IP_CLIENT="192.168.1.100"

# Autoriser la communication entrante vers PostgreSQL depuis l'adresse IP autorisée
iptables -A INPUT -p tcp -s $IP_CLIENT --dport 5432 -j ACCEPT

# Autoriser la communication sortante depuis PostgreSQL vers l'adresse IP autorisée
iptables -A OUTPUT -p tcp -d $IP_CLIENT --sport 5432 -j ACCEPT

# Bloquer tout autre trafic entrant
iptables -A INPUT -j DROP

# Bloquer tout autre trafic sortant
iptables -A OUTPUT -j DROP

## Sécuriser les authentifications distante par PAM

La sécurisation des authentifications distantes par PAM (Pluggable Authentication Modules) est un processus visant à renforcer la sécurité des connexions distantes en utilisant le système PAM sur un serveur Linux.

sudo cp /etc/pam.d/sshd /etc/pam.d/sshd.backup #Crée une copie de sauvegarde du fichier PAM pour le service SSH.

sudo bash -c 'echo "auth required pam_securetty.so" >> /etc/pam.d/sshd' #Ajoute une règle PAM au fichier /etc/pam.d/sshd. La règle ajoutée (auth required pam_securetty.so) renforce les conditions d'authentification pour les connexions distantes.

On ajoute une règle d'authentification supplémentaire au fichier de configuration PAM pour le service SSH (sshd). Cela ajoute la règle "auth required pam_securetty.so" à ce fichier.

auth: Cette règle s'applique au processus d'authentification.

required: Indique que la règle est requise pour permettre l'authentification.

pam_securetty.so: C'est un module PAM qui contrôle les terminaux sur lesquels un utilisateur est autorisé à se connecter. On limite les connexions SSH aux terminaux physiques locaux.

## Sécuriser les accès aux bases utilisateur distantes

Pour ce paramètre, on peut utiliser des certificats pour garantir les échanges.

ici nous prenons l'exemple avec postgresql.

On installe le paquet, et ensuite on vient creer des certificats avec openssl.

apt install postgresql #installation du paquet
mkdir /etc/postgresql/ssl #creation du repertoire
cd /etc/postgresql/ssl #deplace dans ce repertoire

openssl req -new -text -out server.req #Génère une demande de certificat contenant des détails pour obtenir un certificat signé.

openssl rsa -in privkey.pem -out server.key #Extrait la clé privée du fichier PEM pour l'utiliser ultérieurement.

openssl req -x509 -in server.req -text -key server.key -out server.crt #Crée un certificat auto-signé à partir de la demande de certificat et de la clé privée.

chmod 600 server.key #on mets les bon droits a nos certs
chmod 600 server.crt #

On active le ssl et on specifie le chemin ou sont nos cert.

##### On modifie le fichier de conf :

sudo nano /etc/postgresql/15/main/postgresql.conf


On restart le service :

sudo service postgresql restart

On parametre qui peut se connecter au service :

sudo nano /etc/postgresql/15/main/pg_hba.conf


On restart le service :

sudo service postgresql restart

Bien sur on peut automatiser tout cela dans un script bash.

#!/bin/bash

# Mise à jour des paquets
sudo apt-get update

# Installation de PostgreSQL
sudo apt-get install -y postgresql

# Création du répertoire pour les certificats SSL
sudo mkdir /etc/postgresql/ssl
cd /etc/postgresql/ssl

# Génération des certificats SSL
openssl req -new -text -out server.req
openssl rsa -in privkey.pem -out server.key
openssl req -x509 -in server.req -text -key server.key -out server.crt

# Configuration des permissions des certificats
chmod 600 server.key
chmod 600 server.crt

# Configuration de PostgreSQL pour utiliser SSL
sudo bash -c 'echo "ssl = on" >> /etc/postgresql/15/main/postgresql.conf'
sudo bash -c 'echo "ssl_cert_file = '\''/etc/postgresql/ssl/server.crt'\''" >> /etc/postgresql/{version}/main/postgresql.conf'
sudo bash -c 'echo "ssl_key_file = '\''/etc/postgresql/ssl/server.key'\''" >> /etc/postgresql/{version}/main/postgresql.conf'

# Redémarrage de PostgreSQL
sudo service postgresql restart

# Configuration des autorisations d'accès dans pg_hba.conf
sudo bash -c 'echo "hostssl all all {votre_adresse_IP}/32 md5" >> /etc/postgresql/15/main/pg_hba.conf'

# Remplacez {votre_adresse_IP} par l'adresse IP de l'ordinateur distant autorisé à se connecter

# Redémarrage de PostgreSQL pour appliquer les changements
sudo service postgresql restart

## Séparer les comptes système et d’administrateur de l’annuaire
**1. Création de comptes distincts :**
Créez des comptes d'utilisateurs distincts pour les tâches liées au système d'exploitation et à l'administration de l'annuaire.
Évitez d'utiliser des comptes d'administrateurs d'annuaire pour des tâches du système d'exploitation et vice versa.

**2. Attribution des droits d'accès :**
Assurez-vous que les comptes d'administrateurs d'annuaire ont uniquement les droits nécessaires pour effectuer des opérations liées à l'annuaire et ne disposent pas d'accès excessif au système d'exploitation.

**3. Restriction de l'usage de comptes d'administrateurs pour NSS :**
Configurez les paramètres NSS pour n'utiliser que des comptes dédiés au système plutôt que des comptes d'administrateurs d'annuaire.
Assurez-vous que les requêtes d'énumération de comptes par NSS sont effectuées avec des comptes appropriés.

**4. Documentation et formation :**
Documentez clairement la séparation des comptes dans les politiques de sécurité de l'entreprise.
Assurez-vous que les administrateurs système sont formés sur l'importance de maintenir cette séparation.

**5. Contrôles d'audit :**
Configurez des contrôles d'audit pour surveiller les activités liées aux comptes d'administrateurs.
Examinez régulièrement les journaux d'audit pour détecter tout comportement suspect.

**6. Vérification de la conformité :**
Effectuez régulièrement des audits pour évaluer la configuration des comptes, les droits d'accès et les activités liées à l'administration de l'annuaire.
Assurez-vous que la configuration actuelle est conforme aux recommandations de la mesure R70.
## Durcir et surveiller les services exposés

Dans notre cas, nous avons le service postgresql, nous allons donc le "durcir" avec un script, bien sur toutes ces commandes peuvent etre executer manuellement, nous l'avons mis dans un script afin de gagner du temps.

Ce script modifie le port par défaut de PostgreSQL, configure le firewall pour autoriser le trafic sur ce port. Il installe fail2ban pour la protection contre les attaques de force brute, et configure fail2ban pour surveiller les tentatives de connexion à PostgreSQL.

#!/bin/bash

# Modification du port par défaut de PostgreSQL
sudo bash -c 'echo "port = 5432" >> /etc/postgresql/{version}/main/postgresql.conf'

# Redémarrage de PostgreSQL
sudo service postgresql restart

# Configuration du firewall pour autoriser uniquement le trafic nécessaire
sudo ufw allow 5432
sudo ufw enable

# Vérification de l'état du firewall
sudo ufw status

# Installation de fail2ban pour la protection contre les attaques de force brute
sudo apt-get install -y fail2ban

# Copie de la configuration de fail2ban pour PostgreSQL
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo bash -c 'echo "[postgresql]" >> /etc/fail2ban/jail.local'
sudo bash -c 'echo "enabled = true" >> /etc/fail2ban/jail.local'
sudo bash -c 'echo "port = 5432" >> /etc/fail2ban/jail.local'

# Redémarrage de fail2ban
sudo service fail2ban restart

## Rapport lynis apres avoir appliqués ces mesures :

Après l'application des mesures du niveau intermédiaire, nous pouvons voir que notre scan Lynis a bien augmenté, ce qui démontre bien la pertinence de ces mesures.

##### Scan Lynis avant application de ces mesures :

##### Scan Lynis après application de ces mesures :