# Wiki Sécurisation de Linux
*Lien vers le wiki en ligne* : https://hackmd.io/cjG2ZiLITYqviEyILUQQBA?both#R29
**Liens vers rapports annexes :**
[***Rapports Lynis***](https://hackmd.io/yOzK0ZZwRY6_8cjip7KWQw)
[***Différences Rapports Lynis***](https://hackmd.io/av62rw_TSdaFkC0KFzHslg)
### Auteurs: Elie Tricoire, Karl Chardonnay, Jules Henriette, Donatien Jaguelin
## Sommaire
**Règles M**
- [R30: ***Désactiver les comptes utilisateur inutilisés***](#R30)
- [R31: ***Utiliser des mots de passe robustes***](#R31)
- [R53: ***Éviter les fichiers ou répertoires sans utilisateur ou sans groupe connu***](#R53)
- [R54: ***Activer le sticky bit sur les répertoires inscriptibles***](#R54)
- [R56: ***Éviter l'usage d'exécutables avec les droits spéciaux setuid et setgid***](#R56)
- [R58: ***N'installer que les paquets strictement nécessaires***](#R58)
- [R59: ***Utiliser des dépôts de paquets de confiance***](#R59)
- [R61: ***Effectuer des mises à jour régulières***](#R61)
- [R62: ***Désactiver les services non nécessaires***](#R62)
- [R68: ***Protéger les mots de passe stockés***](#R68)
- [R80: ***Réduire la surface d'attaque des services réseau***](#R80)
**Règles MI**
- [R28: ***Partitionnement type***](#R28)
- [R32: ***Éxpirer les sessions utilisateur locales***](#R32)
- [R33: ***Assurer l'imputabilité des actions d'administration***](#R33)
- [R34: ***Désactiver les comptes de service***](#R34)
- [R35: ***Utiliser des comptes de service uniques et exclusifs***](#R35)
- [R39: ***Modifier les directives de configuration sudo***](#R39)
- [R40: ***Utiliser des utilisateurs cibles non-privilégiés pour les commandes sudo***](#R40)
- [R42: ***Bannir les négations dans les spécifications sudo***](#R42)
- [R43: ***Préciser les arguments dans les spécifications sudo***](#R43)
- [R44: ***Éditer les fichiers de manière sécurisée avec sudo***](#R44)
- [R52: ***Restreindre les accès aux sockets et aux pipes nommées***](#R52)
- [R55: ***Séparer les répertoires temporaires des utilisateurs***](#R55)
- [R63: ***Désactiver les fonctionnalités des services non essentielles***](#R63)
- [R67: ***Sécuriser les authentifications distante par PAM***](#R67)
- [R69: ***Sécuriser les accès aux bases utilisateur distantes***](#R69)
- [R70: ***Séparer les comptes système et d'administrateur de l'annuaire***](#R70)
- [R74: ***Durcir le service de messagerie locale***](#R74)
- [R75: ***Configurer un alias de messagerie des comptes de service***](#R75)
- [R79: ***Durcir et surveiller les services exposés***](#R79)
**Règles MIR**
- [R29: ***Restreindre les accès au dossier /boot***](#R29)
- [R36: ***Modifier la valeur par défaut de UMASK***](#R36)
- [R37: ***Utiliser des fonctionnalités de contrôle d'accès obligatoire MAC***](#R37)
- [R38: ***Créer un groupe dédié à l'usage de sudo***](#R38)
- [R41: ***Limiter l'utilisation de commandes nécessitant la directive EXEC***](#R41)
- [R45: ***Activer les profils de sécurité AppArmor***](#R45)
- [R51: ***Changer les secrets et droits d'accès dès l'installation***](#R51)
- [R57: ***Éviter l'usage d'exécutables avec les droits spéciaux setuid root et setgid root***](#R57)
- [R60: ***Utiliser des dépôts de paquets durcis***](#R60)
- [R64: ***Configurer les privilèges des services***](#R64)
- [R65: ***Cloisonner les services***](#R65)
- [R71: ***Mettre en place un système de journalisation***](#R71)
- [R72: ***Mettre en place des journaux d'activité de service dédiés***](#R72)
- [R73: ***Journaliser l'activité système avec auditd***](#R73)
- [R78: ***Cloisonner les services réseau***](#R78)
# Suivre les recommendations de l'ANSSI, en suivant l'ordre pré-établi:
# Règles M :
<a id="R30"></a>
## R30-Désactiver les comptes utilisateur inutilisés
***Type de mesure:*** Minimisation
Sources:
https://unix.stackexchange.com/questions/7690/how-do-i-completely-disable-an-account
https://stackoverflow.com/questions/40188060/how-would-i-disable-accounts-that-have-been-inactive-for-90-days-in-linux
Effectuer cette commande afin de lister tous les comptes utilisateurs qui ne se sont pas connectés depuis 55 jours :
```bash
lastlog -b 55 | awk '!/Never log/ {if (NR > 1) print $1}'
```
Vous pouvez après désactiver les comptes que vous souhaitez en utilisant la commande suivante :
```bash
usermod --lock --expiredate 1970-01-02 <username>
```
---
<a id="R31"></a>
## R31-Utiliser des mots de passe robustes
***Type de mesure:*** Défense en profondeur
Sources:
https://cyber.gouv.fr/publications/recommandations-relatives-lauthentification-multifacteur-et-aux-mots-de-passe
D'après les recommandations de l'ANSSI, un mot de passe robuste doit comporter au moins 15 caractères, soit plus une taille de clé équivalente à plus de 100 bits. Veuillez également utiliser des Majuscules, chiffres et caractères spéciaux. Pour des comptes sensibles, pensez à changer de mots de passe tout les 3-6 mois.
---
<a id="R53"></a>
## R53-Éviter les fichiers ou répertoires sans utilisateur ou sans groupe connu
***Type de mesure:*** Moindre privilège
La commande suivante permet de lister l’ensemble des fichiers qui n’ont plus d’utilisateur ou de groupe associé :
```bash
find / -type f \( -nouser -o -nogroup \) -ls 2>/dev/null
```
Les répertoires accessibles en écriture à tous sont souvent utilisés comme espaces de stockage temporaires, où une application enregistre des données en vue de leur traitement ultérieur. Cependant, de nombreuses applications les utilisent de manière incorrecte, ce qui peut entraîner une utilisation abusive des fichiers temporaires, par exemple, en tant que point de rebond pour une escalade de privilèges.
Pour remédier à cela, une solution consiste à activer le bit collant (sticky bit) sur le répertoire. Cela permet de restreindre la suppression des fichiers temporaires uniquement à l'utilisateur ou à l'application qui les a créés. Ainsi, cette mesure prévient toute suppression ou remplacement arbitraire de fichiers temporaires par d'autres utilisateurs ou applications.
---
<a id="R54"></a>
## R54-Activer le sticky bit sur les répertoires inscriptibles
***Type de mesure:*** Moindre privilège
Tous les répertoires accessibles en écriture par tous doivent avoir le sticky bit positionné.
Il faut s’assurer que le propriétaire du répertoire est bien root, sans quoi l’utilisateur propriétaire pourra à loisir modifier son contenu et ce malgré le sticky bit.
la commande suivante permet de lister l’ensemble des répertoires modifiables par tous et sans sticky bit :
```bash
find / -type d \( -perm -0002 -a \! -perm -1000 \) -ls 2>/dev/null
```
La commande suivante permet de lister l’ensemble des répertoires modifiables par
tous et dont le propriétaire n’est pas root :
```bash
find / -type d -perm -0002 -a \! -uid 0 -ls 2>/dev/null
```
Vous pouvez ajouter des sticky bits en utilisant la commande suivante :
```bash
chmod o+t /opt/dump/
```
---
<a id="R56"></a>
## R56-Éviter l'usage d'exécutables avec les droits spéciaux *setuid* et *setgid*
***Type de mesure:*** Moindre privilège
Lors de l'installation de paquets et/ou d'éxécutables, il faut parfois un certain niveau d'élévation de droits pour l'éxécution de ces fichiers. Si ces droits sont prészeznt s sur des fichiers provenant de dépôt externes, il y a un risque important et le serveur peut être mis en péril. (d'où l'importance de la R59).
Commande pour lister l'ensemble des fichiers avec les droits *setuid* et *setgid*:
```bash
find / -type f -perm /6000 -ls 2>/dev/null
```
Commande pour retirer les droits des fichiers:
```bash
chmod u-s <fichier > # Retire le droit spécial setuid
chmod g-s <fichier > # Retire le droit spécial setgid
chmod -s <fichier > # Retire le droit spécial setgid et setuid
```
Cas pratique:
Si on regarde les fichiers avec des droits spéciaux on peut percevoir un fichier avec ces droits, qui n'est pas censé avoir ces droits:
Si on regarde le contenu du message on peut voir que c'est une liste de choses à faire.
Donc en utilisant les commandes ci-dessus, on enlève les droits spéciaux de ce fichier. On peut voir, une fois la commande exécutée que le fichier ne possède plus ces droits:
---
<a id="R58"></a>
## R58-N'installer que les paquets strictement nécessaires
***Type de mesure:*** Minimisation
Il est important de privilégier une installation minimale en sélectionnant uniquement les paquets nécessaires pour répondre aux besoins spécifiques. Pour parvenir à une installation minimale, il est souvent plus pratique de désélectionner tous les paquets préinstallés et de n'installer que ceux indispensables à l'usage prévu. Par exemple, lors de la configuration d'un serveur, il n'est pas primordial d'avoir une interface graphique locale pour la manipulation du serveur.
Commande pour installer des paquets
```bash
sudo apt-get install nom_du_paquet
```
---
<a id="R59"></a>
## R59-Utiliser des dépôts de paquets de confiance
***Type de mesure:*** Minimisation
En lien avec la mesure précédente(R58), les paquets à installer doivent prévenir seulement des dépots qui sont internes à la distribution de la VM. Pour la VM kali, un fichier contient tout les liens sources pour l'installation de paquets:
```bash
/etc/apt/sources.list
```
On peut rajouter des dépôts externes à l'organisation en modifiant le fichier:
Commande pour modifier le fichier de dépôt:
```bash
nano /etc/apt/sources.list
```
Bien sûr avant de rajouter un dépôt à la BDD, il faut se poser les questions suivantes:
Est-ce que mon dépôt est sûr?
Quelles sont les risques d'introduire des dépôts externes dans notre organisations?
Est-ce que le risque en vaut la chandelle ?
---
<a id="R61"></a>
## R61-Effectuer des mises à jour régulières
***Type de mesure:*** Veille et maintenance
Sources:
https://www.debian.org/doc/manuals/securing-debian-manual/ch10.en.html#keep-up-to-date
https://help.ubuntu.com/community/AutoWeeklyUpdateHowTo
Veuillez tout d'abord installer cron-apt :
```bash
apt-get install cron-apt
```
Si votre système est normalement éteint à 4 heures du matin, vous pouvez soit éditer /etc/cron.d/cron-apt et modifier la programmation à une heure à laquelle votre PC est susceptible d'être allumé, soit utiliser Anacron pour qu'il s'exécute à la prochaine mise sous tension de votre PC.
Ainsi, en créant un lien symbolique dans le répertoire /etc/cron.weekly/ pointant vers l'exécutable cron-apt, il configure cron-apt pour qu'il soit exécuté chaque semaine.
```bash
sudo ln -s /usr/sbin/cron-apt /etc/cron.weekly/
```
---
<a id="R62"></a>
## R62-Désactiver les services non nécessaires
***Type de mesure:*** Minimisation
PS: Avant de faire des modifications, il est conseillé de faire des snapshots.
Commande pour lister l'ensemble des services installés sur le système :
```bash
systemctl list-units --type service
```
Commande pour lister l'ensemble des services installés inactifs sur le système :
```bash
systemctl list-units --type=service --state=inactive
```
Il suffit ensuite de trier parmi les services inactifs pour les désinstaller.
Commande pour désinstaller les services non-nécessaires:
```bash
sudo systemctl stop nom_du_service
sudo systemctl disable nom_du_service
sudo yum remove nom_du_paquet
```
Cas pratique :
Sur le serveur on a un service qui s'intitule "wpa_supplicant.service", qui est un service pour la gestion de connexion aux réseaux Wi-Fi. Sur un serveur Linux, ce type de service ne nous aient pas utilie. Par conséquent on peut le supprimer comlètement du périphérique.
Commande pour supprimer un service:
```bash
systemctl kill wpa_supplicant.service
```
Sur les serveurs linux, le service bluetooth n'est pas nécessaire sur la machine. Si sur l'hôte physique, le service bluetooth est présent en USB, il peut se retrouver sur la machine virtuelle (à condition d'avoir paramétrer correctement la configuration de virtualbox). Il faut donc le supprimer, à l'aide des commandes au-dessus.Ce service ne sera pas présent si Bluetooth est présent en tant que PKI.
---
<a id="R68"></a>
## R68-Protéger les mots de passe stockés
***Type de mesure:*** Défense en profondeur
L'authentification par mot de passe reste pertinente, les fuites de la base de données de hachage de mot de passe se produisent, les fuites ne sont pas toujours détectées et entièrement traitées correctement loin, et même une fois qu'il s'agit de mots de passe identiques ou similaires pour de nombreux utilisateurs réutilisés ailleurs restent exposés.
yescrypt est une fonction de dérivation de clé (KDF) et un mot de passe basés sur un mot de passe schéma de hachage.
PAM peut être configuré afin d’utiliser yescrypt en ajoutant dans le fichier **/etc/pam.d/common-password** la directive suivante :
password required pam_unix.so obscure yescrypt rounds=11
Et si le système est trop ancien pour utilisé yescrypt il faut utilisé SHA-512crypt mais en augmentant le nombre de tours :
password required pam_unix.so obscure sha512 rounds=65536
<a id="R80"></a>
## R80-Réduire la surface d'attaque des services réseau
***Type de mesure:*** Minimisation
Tous les services réseau doivent être en écoute sur les interfaces réseau adéquates.
Il est possible de lister les processus avec leurs ports et inteface associé avec :
stockstat
Il faut ensuite examiné la liste des services pour identifier ceux qui ne devraient pas être en écoute sur des interfaces réseau externes ou non sécurisées..
Pour chaque service qui n'a pas besoin d'être accessible depuis le réseau externe, il faut le configurer pour qu'il soit en écoute uniquement sur une interface locale.
On peut ensuite configuer le par-feu windows pour ajouter plus de sécurité.
# Règles MI :
<a id="R28"></a>
## R28-Partitionnement type
***Type de mesure:*** Veille et maintenace
Le schéma de partitionnement recommandé pour un système GNU/Linux est le suivant, avec les options spécifiées pour chaque point de montage :
- `/` (racine): Partition principale qui contient le reste de la structure de fichiers.
- `/boot`: Contient le noyau et le chargeur de démarrage, monté avec les options `nosuid,nodev,noexec`. Cette partition n'est pas automatiquement montée au démarrage, sauf lors de mises à jour.
- `/opt`: Packages additionnels au système, montés avec les options `nosuid,nodev` (optionnellement en lecture seule).
- `/tmp`: Fichiers temporaires, montés avec les options `nosuid,nodev,noexec`. Ne doit contenir que des éléments non exécutables. Nettoyé après le redémarrage ou préférablement de type `tmpfs`.
- `/srv`: Contient des fichiers servis par des services tels que Web, FTP, etc. Monté avec les options `nosuid,nodev` (optionnellement `noexec` et en lecture seule).
- `/home`: Contient les répertoires HOME des utilisateurs, monté avec les options `nosuid,nodev,noexec`.
- `/proc`: Contient des informations sur les processus et le système, monté avec l'option `hidepid=2`.
- `/usr`: Contient la majorité des utilitaires et fichiers système, monté avec l'option `nodev`.
- `/var`: Partition contenant des fichiers variables pendant la vie du système (mails, fichiers PID, bases de données d'un service), montée avec les options `nosuid,nodev,noexec`.
- `/var/log`: Contient les logs du système, monté avec les options `nosuid,nodev,noexec`.
- `/var/tmp`: Fichiers temporaires conservés après extinction, monté avec les options `nosuid,nodev,noexec`.
Il est important de noter que certaines options de montage peuvent ne pas être applicables transitoirement en fonction des systèmes et distributions. Dans ces cas, des ajustements du partitionnement ou des alternatives peuvent être nécessaires. Par exemple, certaines distributions dérivées de Debian nécessitent des droits d'exécution dans `/tmp` ou `/var`, et des procédures de maintenance spécifiques peuvent être mises en place.
En ce qui concerne la partition `/boot`, elle contient le noyau de démarrage et les fichiers `System.map` utilisés par celui-ci. La recommandation est de ne pas monter automatiquement cette partition au démarrage (`noauto`), car son contenu est généralement inutile en phase d'utilisation normale du système. Cependant, son montage est indispensable pour effectuer des actions d'administration telles que la mise à jour du noyau.
---
<a id="R32"></a>
## R32-Éxpirer les sessions utilisateur locales
***Type de mesure:*** Moindre privilège
Implenter un timeout sur les comptes utilisateurs présente une protection supplémentaire dans le grand schéma d'une configuration Linux sécurisé. Il est possible d'implémenter cette fonction via le chemin suivant:
```bash
sudo nano /etc/systemd/logind.conf
```
Modifier la ligne suivant pour :
IdleAction=lock
Puis ajouter le temps limite avant que la session se vérrouille.
IdleActionSec=15min
Enregistrer le fichier et redémarrer le service :
```bash
sudo systemctl restart systemd-logind
```
---
<a id="R33"></a>
## R33-Assurer l'imputabilité des actions d'administration
***Type de mesure:*** Moindre privilège
Les actions d’administration nécessitant des privilèges doivent être tracées afin de pouvoir identifier l’administrateur à l’origine d’une activité malveillante.
Une des posibilité est de créer un compte administrateur par service **(www-data pour apache2 par exemple)**, et ne pas utilisé le compte administrateur **root**.
Il est possible de désactiver un compte avec les commandes suivante :
Verrouillage d'un compte :
```bash
usermod -L -e 1 <compte>
```
Désactivation du shell de login :
```bash
usermod -s /bin/false <compte>
```
Une seconde méthode, plus puissante, consiste à identifier l’utilisateur de manière unique sur le système, puis à journaliser la création de tout processus avec auditd.
Il est possible de journaliser la création de processus sur le système avec les règles auditd suivantes :
-a exit,always -F arch=b64 -S execve,execveat
-a exit,always -F arch=b32 -S execve,execveat
(Attentions à la quantité de logs générer)
---
<a id="R34"></a>
## R34-Désactiver les comptes de service
***Type de mesure:*** Moindre privilège
Pour désactiver un compte de service sous Debian, vous pouvez utiliser la commande `usermod` pour modifier les attributs du compte, notamment en le désactivant. Voici comment vous pouvez le faire :
Supposons que vous souhaitez désactiver le compte d'un utilisateur de service appelé "serviceuser". Remplacez "serviceuser" par le nom de votre utilisateur de service.
```bash
sudo usermod --expiredate 1 serviceuser
```
Cette commande utilise l'option `--expiredate` pour définir une date d'expiration du compte. La valeur `1` signifie que le compte expirera immédiatement, désactivant ainsi le compte.
Vous pouvez également utiliser la commande `passwd` pour verrouiller le compte en définissant un mot de passe expiré. Cela a un effet similaire :
```bash
sudo passwd --expire serviceuser
```
Après avoir désactivé le compte, l'utilisateur ne pourra plus se connecter au système. Cependant, veillez à prendre en compte les implications potentielles sur les services ou les applications qui utilisent ce compte.
Si vous avez plusieurs comptes de service à gérer, vous pouvez créer un script ou utiliser des commandes similaires de manière itérative pour désactiver plusieurs comptes en une seule fois.
N'oubliez pas de toujours effectuer ces opérations avec un utilisateur disposant des privilèges administratifs (`sudo`).
---
<a id="R35"></a>
## R35-Utiliser des comptes de service uniques et exclusifs
***Type de mesure:*** Moindre privilège
Lorsque vous utilisez Debian, il est une bonne pratique d'attribuer des comptes de service uniques et dédiés à chaque service métier (comme nginx, PHP, MySQL, etc.). Cela contribue à renforcer la sécurité en limitant les permissions et les accès aux ressources système.
Voici les étapes générales pour créer des comptes de service dédiés sous Debian :
1. **Création d'un compte utilisateur :**
Utilisez la commande `adduser` pour créer un nouveau compte utilisateur pour chaque service métier. Par exemple, pour créer un compte pour Nginx :
```bash
sudo adduser --system --no-create-home --group nginx
```
- L'option `--system` crée un compte système sans possibilité de connexion.
- L'option `--no-create-home` évite la création d'un répertoire personnel pour l'utilisateur.
- L'option `--group` crée un groupe portant le même nom que l'utilisateur.
Répétez cette étape pour chaque service métier que vous souhaitez ajouter.
2. **Attribution des permissions :**
Modifiez les permissions sur les fichiers et les répertoires nécessaires pour chaque compte de service. Par exemple, si votre service nécessite l'accès à un répertoire particulier, assurez-vous que le compte de service a les autorisations appropriées.
```bash
sudo chown -R nginx:nginx /chemin/vers/repertoire
```
Cela attribue la propriété du répertoire au compte et au groupe Nginx.
3. **Configuration des services :**
Mettez à jour les fichiers de configuration des services pour utiliser les comptes de service créés. Vous devrez généralement spécifier le nom du compte de service dans les fichiers de configuration des services.
Par exemple, pour Nginx, vous pourriez trouver une ligne comme celle-ci dans le fichier de configuration :
```nginx
user nginx;
```
Assurez-vous que le compte de service approprié est spécifié dans chaque fichier de configuration correspondant.
---
<a id="R39"></a>
## R39-Modifier les directives de configuration sudo
***Type de mesure:*** Moindre privilège
Les directives suivantes doivent être activées par défaut :
- **noexec** appliquer le tag NOEXEC par défaut sur les commandes
- **requiretty** imposer à l’utilisateur d’avoir un tty de login
- **use_pty** utiliser un pseudo-tty lorsqu’une commande est exécutée
- **umask=0077** forcer umask à un masque plus restrictif
- **ignore_dot** ignorer le « . » dans $PATH
- **env_reset** réinitialiser les variables d’environnement
Le fichiers contenant la liste des utilisateur sudo (**/etc/sudoers**) doit avoir la config suivante :
Defaults noexec,requiretty ,use_pty ,umask=0027
Defaults ignore_dot ,env_reset
---
<a id="R40"></a>
## R40-Utiliser des utilisateurs cibles non-privilégiés pour les commandes sudo
***Type de mesure:*** Moindre privilège
Il faut limtter au minimum le nombre d'utilisateurs ayant l'acces au root. (politique du moindre droit)
---
<a id="R42"></a>
## R42-Bannir les négations dans les spécifications sudo
***Type de mesure:*** Moindre privilège
Les spécifications de commande ne doivent pas comporter de négation. Lorsqu'il s'agit de déterminer l'exécutabilité d'une commande par un utilisateur, sudo compare la commande souhaitée aux spécifications du fichier sudoers en utilisant les règles de globbing shell. Cette comparaison inclut également les arguments associés à la commande.
Les arguments peuvent significativement altérer le comportement d'un logiciel, que ce soit en termes d'opérations effectuées (lecture, écriture, suppression, etc.) ou d'accès à des ressources spécifiques dans une arborescence. Afin de prévenir tout risque de détournement d'une commande par un utilisateur, il est impératif d'éliminer toute ambiguïté dans la spécification de la commande.
---
<a id="R43"></a>
## R43-Préciser les arguments dans les spécifications sudo
***Type de mesure:*** Moindre privilège
Les directives du fichier de configuration sudoers doivent spécifier de manière stricte les arguments autorisés pour un utilisateur donné. L'utilisation du caractère générique * (wildcard) dans les règles doit être évitée autant que possible. L'absence d'arguments pour une commande doit être indiquée explicitement par une chaîne vide ("").
Dans certains systèmes, l'accès aux événements du noyau est limité à l'utilisateur root. Si un utilisateur doit néanmoins avoir les privilèges nécessaires pour afficher ces événements, il est essentiel de restreindre les arguments afin d'empêcher la lecture de fichiers arbitraires via l'option --file, comme illustré dans l'exemple suivant :
```bash
user ALL = dmesg ""
```
Il est crucial de noter que permettre à un utilisateur non privilégié d'exécuter un logiciel sous l'identité root, susceptible de réaliser une écriture arbitraire en raison d'une règle trop permissive, équivaut effectivement à accorder à cet utilisateur les privilèges de root. Cela pourrait se produire si l'utilisateur peut, par diverses méthodes (manipulation des fichiers de mots de passe, modification de binaires setuid root, etc.), obtenir les privilèges de root sans le contrôle d'accès et d'exécution fourni par sudo.
Il est courant d'autoriser l'édition d'un fichier par un utilisateur via sudo en appelant directement un éditeur de texte. Cependant, cela peut présenter des risques, car certains éditeurs de texte peuvent exécuter des commandes internes ou même des scripts shell, offrant ainsi un environnement privilégié à l'utilisateur. L'utilisation de l'éditeur de texte `sudoedit` résout ces problèmes en laissant l'éditeur modifier un fichier temporaire avec les droits de l'utilisateur courant, puis en remplaçant le fichier d'origine une fois l'opération terminée. Ainsi, l'éditeur s'exécute uniquement avec les droits de l'utilisateur courant, sans jamais bénéficier des privilèges de l'utilisateur cible.
---
<a id="R44"></a>
## R44-Éditer les fichiers de manière sécurisée avec *sudo*
***Type de mesure:*** Moindre privilège
Lorsqu'une application sous AppArmor exécute un autre programme, son profil de sécurité détermine comment cette transition s'effectue, que ce soit en conservant ou en changeant le profil de sécurité.
AppArmor est un système de sécurité pour GNU/Linux, utilisé par défaut dans les distributions SUSE et Ubuntu. C'est un mécanisme de contrôle d'accès mandatoire (MAC) où une autorité centralisée détermine les accès des applications.
Installation d'AppArmor
- **Vérification de l'activation** : Vérifiez si AppArmor est activé en utilisant une commande comme sudo apparmor_status.
- **Compréhension des Profils** : les règles d'accès pour les applications et se trouvent généralement dans /etc/apparmor.d/.
- **Surveillance et Audit** : Utilisez des outils comme auditd pour surveiller les actions et les éventuelles violations de règles.
- **Mises à jour régulières** : Gardez vos profils à jour avec les changements dans vos applications et systèmes pour assurer une protection continue.
---
<a id="R52"></a>
## R52-Restreindre les accès aux sockets et aux pipes nommées
***Type de mesure:*** Moindre privilège
Pour protéger l'accès aux sockets et aux pipes nommés sur Linux, Il faut prendre en compte les droits d'accès sur le répertoire contenant ces objets, ainsi que les droits d'accès spécifiques à chaque socket ou pipe nommé. Voici comment il faut procéder :
Ajouter des droits sur le fichier parent des pipes:
chmod 700 /chemin/vers/repertoire
Il est aussi possible d'ajouter les droits sur une pipe plus précise avec la même commande.
---
<a id="R55"></a>
## R55-Séparer les répertoires temporaires des utilisateurs
***Type de mesure:*** Moindre privilège
Comme indiqué dans le guide de sécurisation Linux de Linux, l'utilisation de PAM est nécessaire, en l'occurence pam_mktemp.
En premier lieu, il faut installer le paquet pam_mktemp:
apt-get install pam_mktemp
Une fois installé, il faut ouvrir le fichier de configuration associé à la gestion des sessions "/etc/pam.d/common-session" ou similaire.
Dans ce fichier de configuration, il faut ajouter la ligne pam_mktemp:
session required pam_unix.so
session required pam_mkhomedir.so skel=/etc/skel/ umask=0022
session required pam_mktemp.so
Cette configuration ajoute pam_mktemp après pam_unix.so et pam_mkhomedir.so, assurant ainsi la création de répertoires temporaires pour chaque utilisateur lors de leur connexion.
Ne pas oublier de redémarrer le service PAM:
sudo systemctl restart <nom_du_service_PAM>
---
<a id="R63"></a>
## R63-Désactiver les fonctionnalités des services non essentielles
***Type de mesure:*** Minimisation
Les fonctionnalités activées au niveau des services démarrés doivent être strictement limitées aux besoins essentiels.
Il est important de noter que la configuration par défaut de certains services tels que SMTP (Exim, Postfix), NTP (ntpd), et DNS (Bind) est souvent incomplète. Il est donc nécessaire de vérifier et de compléter leur configuration pour garantir une sécurité optimale.
Le noyau Linux subdivise les privilèges traditionnellement associés au compte d'administrateur système (root) en unités distinctes appelées "Linux capabilities". Ces capabilities peuvent être activées ou désactivées de manière indépendante, et elles ne se limitent pas aux processus, mais s'appliquent également aux fichiers exécutables.
Il est crucial de souligner que le noyau Linux propose actuellement 41 capabilities, dont au moins 19 permettent d'élever facilement les droits à ceux de l'utilisateur root (UID=0) (privilèges complets). La plupart des autres capabilities peuvent également fortement contribuer à obtenir un accès root sur le système.
Pour identifier les fichiers exécutables pour lesquels une ou plusieurs Linux capabilities ont été activées, vous pouvez utiliser la commande suivante :
```bash
find / -type f -perm /111 -exec getcap {} \; 2>/dev/null
```
Cette commande listera l'ensemble des fichiers exécutables avec des Linux capabilities activées, fournissant ainsi une vue exhaustive des autorisations potentielles dans le système.
---
<a id="R67"></a>
## R67-Sécuriser les authentifications distante par PAM
***Type de mesure:*** Défense en profondeur
Lorsque l'authentification s'effectue à travers une application distante (via le réseau), le protocole d'authentification utilisé par PAM doit être sécurisé. Cela implique le chiffrement du flux, l'authentification du serveur distant, et la mise en place de mécanismes d'anti-rejeu.
Certains protocoles, tels que Kerberos, offrent des fonctionnalités de communication sécurisée. Par exemple, le module `pam_krb5` peut être utilisé avec un fichier keytab host configuré pour le système.
D'autres modules, comme `pam_ldap` ou `pam_mysql`, n'établiront pas automatiquement une communication sécurisée entre le client PAM et l'application, à moins d'être explicitement configurés en ce sens.
En plus de l'authentification, PAM permet de charger d'autres modules dont les fonctionnalités peuvent améliorer la sécurité du système. Quelques exemples incluent :
- `pam_faillock`: permet de bloquer temporairement un compte après un certain nombre d'échecs.
- `pam_time`: restreint les accès à une plage horaire.
- `pam_passwdqc`: applique des contraintes selon une politique de complexité de mots de passe.
- `pam_pwquality`: teste la robustesse des mots de passe.
- `pam_wheel`: restreint l'accès aux utilisateurs membres d'un groupe particulier (généralement le groupe "wheel").
- `pam_mktemp`: fournit des répertoires temporaires privés par utilisateur sous `/tmp`.
- `pam_namespace`: crée un espace de noms privé par utilisateur.
Un exemple de configuration PAM est fourni, montrant des directives spécifiques pour certains services dans les fichiers de configuration situés sous `/etc/pam.d/`. Par exemple, le fichier `/etc/pam.d/su` et `/etc/pam.d/su-l` limite l'utilisation de la commande `su` pour devenir root aux utilisateurs membres du groupe "wheel". De même, le fichier `/etc/pam.d/passwd` établit des règles de complexité pour les mots de passe, tandis que les fichiers `/etc/pam.d/login` et `/etc/pam.d/sshd` bloquent automatiquement des comptes après un certain nombre d'échecs.
Il est souligné que le stockage des mots de passe en clair est strictement interdit, car la compromission du système permettrait à un attaquant de les réutiliser facilement pour d'autres services. La sécurité des mots de passe ne doit pas dépendre uniquement des droits d'accès à une base.
---
<a id="R69"></a>
## R69-Sécuriser les accès aux bases utilisateur distantes
***Type de mesure:*** Moindre privilège
NSS, ou Network Security Services, est une collection de bibliothèques conçues pour supporter le développement d'applications sécurisées.
Pour le mettre en place NSS il faut :
- Configuration de NSS pour une liaison sécurisée :
- il faut mettre en place une liaison sécurisée qui doit inclure l'authentification du serveur et la protection du canal de communication, généralement via SSL/TLS.
- Cela implique l'utilisation de certificats pour authentifier le serveur. Vous devriez obtenir un certificat de serveur de confiance
- Authentification pour l'accès aux bases de données :
- Pour accéder à des bases de données il faut configurez NSS pour qu'il utilise un compte d'authentification dédié.
- Ce compte doit être distinct des comptes utilisateur normaux du système. Il doit s'agir d'un compte avec des privilèges limités.
- Gestion des droits d'accès :
- Le compte utilisé par NSS ne doit avoir que les droits strictement nécessaires pour interroger la base de données.
- Il est essentiel de respecter le principe du moindre privilège, garantissant que chaque utilisateur ou service dispose uniquement des droits nécessaires à ses fonctions.
- Surveillez régulièrement l'utilisation du système pour détecter toute activité suspecte.
- après la configuration il faut mettre à jour le système, le logiciel NSS, et les certificats de sécurité pour assurer une protection continue.
---
<a id="R70"></a>
## R70-Séparer les comptes système et d'administrateur de l'annuaire
***Type de mesure:*** Défense en profondeur
La sécurité de ce point se focalise sur la séparation des comptes systèmes et administrateurs.
Nous pouvons mettre en oeuvre plusieurs pour améliorer la sécurité:
**Utilisation de comptes distincts:**
Assurez-vous que les comptes système utilisés par le système d'exploitation et les comptes d'administrateur de l'annuaire sont distincts. Les comptes de tous les jours ne doivent pas être utilisé pour configurer l'annuaire par exemple.
**Gestion des droits d'accès:**
Cela parrait evident mais il est nécessaire d'instaurer des privilèges différents en fonction des utilisateurs.
**Contrôle d'accès:**
Un contrôle d'accès est plus que recommandé. Utiliser desliste de contrôle d'accès (ACL) si vous voulez restreindre les accès à des ressources spécifiques.
**Restriction des requêtes d'énumération de comptes par NSS :**
Prohibez spécifiquement l'usage de comptes administrateur d'annuaire pour effectuer des requêtes d'énumération de comptes par NSS (Name Service Switch). Ceci peut être réalisé en configurant correctement les droits d'accès et les autorisations pour éviter que les comptes d'administration soient utilisés de manière inappropriée.
---
<a id="R74<a id="R62"></a>"></a>
## R74-Durcir le service de messagerie locale
***Type de mesure:*** Défense en profondeur
Une considération importante est liée à la configuration par défaut des services de messagerie qui envoient souvent des messages au compte de l'administrateur système (root). Étant donné que la recommandation R33 suggère de désactiver le compte root, il est nécessaire de mettre en place des mécanismes, tels que des alias, pour ne pas perdre les messages adressés à l'administrateur système.
**Implémentation :**
Pour mettre en œuvre cette règle sur Debian 12, suivez ces étapes :
1. **Configuration du Service de Messagerie :**
- Utilisez le gestionnaire de paquets Debian (apt) pour installer un serveur de messagerie local, tel que Postfix.
```bash
sudo apt-get install postfix
```
- Pendant l'installation, choisissez l'option appropriée pour configurer le serveur de messagerie en tant que "Serveur local".
2. **Restriction des Destinataires Locaux :**
- Éditez le fichier de configuration de Postfix pour restreindre l'acceptation des messages uniquement aux destinataires locaux.
```bash
sudo nano /etc/postfix/main.cf
```
Ajoutez ou modifiez la ligne suivante :
```
mydestination = localhost
```
Redémarrez le service Postfix.
```bash
sudo systemctl restart postfix
```
3. **Rejet des Connexions Distantes :**
- Assurez-vous que le service de messagerie n'écoute que sur l'interface réseau de la boucle locale.
```bash
sudo nano /etc/postfix/main.cf
```
Vérifiez que la ligne suivante est présente :
```
inet_interfaces = loopback-only
```
Redémarrez le service Postfix.
```bash
sudo systemctl restart postfix
```
4. **Configuration d'Alias pour l'Administrateur Système :**
- Utilisez un éditeur de texte pour modifier le fichier d'alias.
```bash
sudo nano /etc/aliases
```
Ajoutez une entrée pour rediriger les messages de l'administrateur système vers un utilisateur existant :
```
root: votre_utilisateur
```
Appliquez les modifications.
```bash
sudo newaliases
```
Ces étapes permettent de configurer le service de messagerie pour répondre aux exigences de la règle en n'acceptant que des messages locaux et en rejetant les connexions distantes. De plus, la redirection des messages destinés à l'administrateur système est assurée par la configuration d'alias.
---
<a id="R75"></a>
## R75-Configurer un alias de messagerie des comptes de service
***Type de mesure:*** Défense en profondeur
Il est recommandé de configurer des alias de messagerie pour chaque compte de service exploité sur le système, ainsi que pour le compte d'administrateur (root). Cela garantit que les notifications et les rapports générés par ces services seront dirigés vers un compte utilisateur administrateur désigné, facilitant ainsi la gestion centralisée des alertes.
**Implémentation :**
Suivez ces étapes pour mettre en œuvre cette règle :
1. **Éditer le Fichier d'Aliases :**
- Utilisez un éditeur de texte pour modifier le fichier d'aliases.
```bash
sudo nano /etc/aliases
```
2. **Ajouter des Alias pour les Comptes de Service :**
- Ajoutez des entrées pour chaque compte de service que vous souhaitez rediriger vers un compte administrateur. Remplacez `service1`, `service2`, et `votre_utilisateur` par les noms de compte appropriés.
```plaintext
service1: votre_utilisateur
service2: votre_utilisateur
```
3. **Ajouter un Alias pour le Compte d'Administrateur (root) :**
- Ajoutez une entrée pour rediriger les notifications du compte root.
```plaintext
root: votre_utilisateur
```
4. **Appliquer les Modifications :**
- Après avoir modifié le fichier d'aliases, appliquez les changements.
```bash
sudo newaliases
```
5. **Test de la Configuration :**
- Envoyez un message de test à l'un des comptes de service configurés et assurez-vous qu'il est correctement redirigé vers le compte administrateur désigné.
```bash
echo "Ceci est un message de test" | mail -s "Test" service1
```
**Note :** Assurez-vous que le service de messagerie configuré sur votre système est fonctionnel et peut envoyer des notifications par courrier électronique.
En configurant des alias de messagerie, vous assurez que les comptes de service et le compte d'administrateur reçoivent les notifications et les rapports pertinents. Cela contribue à centraliser les communications critiques vers des comptes administrateurs spécifiques, facilitant ainsi la surveillance et la gestion des alertes système.
---
<a id="R79"></a>
## R79-Durcir et surveiller les services exposés
***Type de mesure:*** Veille et maintenance
Les services exposés à des flux non maîtrisés doivent être durcis et particulièrement
surveillés.
Cette surveillance consiste à caractériser le comportement du service, et à reporter
tout écart par rapport à son fonctionnement nominal déduit des spécifications initiales attendues.
Les services réseau sont souvent configurés par défaut en écoute sur l’ensemble des interfaces réseau, augmentant inutilement leur surface d’attaque.
Un srveur qui utilise un service Web reposant sur une authentification HTTP basique peut être exploitable
à plusieurs niveaux :
-matériel (micrologiciel 44, pilote logiciel de cartes réseau…);
-réseau (Ethernet, IP, TCP);
a-pplicatif (couche SSL/TLS, en-têtes HTTP émis et reçus avant l’authentification).
***Recommendations à mettre en place***
1. **Restriction des Interfaces Réseau :**
Configurez les services pour n'écouter que sur les interfaces réseau nécessaires. Limitez l'exposition en désactivant la prise en charge des interfaces non utilisées.
Utilisez des pare-feu pour contrôler le trafic entrant et sortant. Bloquez tout trafic non autorisé.
2. **Durcissement des Services :**
Suivez les meilleures pratiques de sécurité pour chaque service spécifique que vous exposez.
Désactivez les fonctionnalités inutiles et configurez les paramètres de sécurité recommandés.
Mettez en œuvre des mécanismes d'authentification forte lorsque cela est possible.
3. **Surveillance du Comportement :**
Mettez en place des outils de surveillance pour suivre en temps réel le comportement des services exposés.
Établissez des baselines en comprenant le fonctionnement normal du service, puis configurez des alertes pour détecter les anomalies.
Incluez la surveillance des journaux système pour capturer des informations importantes.
4. **Rapport des Écarts :**
Configurez un système de gestion des incidents pour signaler rapidement tout écart par rapport au fonctionnement nominal.
Développez des procédures pour enquêter sur ces écarts, identifier les causes sous-jacentes et mettre en œuvre des correctifs.
5. **Gestion des Mises à Jour :**
Gardez à jour tous les logiciels et micrologiciels pour remédier aux vulnérabilités connues.
Mettez en place une politique de gestion des mises à jour pour assurer la maintenance continue du système.
---
---
# Règles MIR :
<a id="R29"></a>
## R29-Restreindre les accès au dossier /boot
***Type de mesure:*** Moindre privilège
**Implémentation :**
1. **Sauvegarde :**
Avant toute modification, assurez-vous de créer une sauvegarde complète du système ou au moins des configurations critiques pour pouvoir restaurer en cas de problème.
2. **Édition du Fichier /etc/fstab :**
Ouvrez le fichier /etc/fstab, qui contient les informations de montage des partitions. Trouvez la ligne correspondante à la partition /boot et ajoutez l'option "noauto" pour éviter le montage automatique.
```bash
# Éditez le fichier /etc/fstab
sudo nano /etc/fstab
```
Modifiez la ligne :
```
/dev/sdXY /boot ext4 defaults 0 2
```
En :
```
/dev/sdXY /boot ext4 defaults,noauto 0 2
```
3. **Mise à Jour du Système de Démarrage :**
Assurez-vous que les outils de gestion du noyau et du chargeur de démarrage sont compatibles avec la modification. Cela peut nécessiter l'installation de versions spécifiques ou la configuration des scripts de mise à jour.
4. **Restreindre les Accès au Dossier /boot :**
Définissez les autorisations appropriées pour le dossier /boot afin que seul l'utilisateur root puisse y accéder.
```bash
# Réglez les autorisations pour /boot
sudo chown root:root /boot
sudo chmod 700 /boot
```
5. **Configuration de dpkg :**
Configurez dpkg pour effectuer des actions spécifiques avant ou après l'installation de paquets. Vous pouvez utiliser le fichier de configuration /etc/dpkg/dpkg.cfg.d/.
```bash
# Créez le fichier de configuration pour dpkg
sudo nano /etc/dpkg/dpkg.cfg.d/01_noauto_boot
# Ajoutez la ligne suivante pour empêcher le montage automatique de /boot
noauto /boot
```
6. **Vérification :**
Redémarrez le système et assurez-vous que la partition /boot n'est pas montée automatiquement. Vérifiez également que seuls l'utilisateur root a accès au dossier /boot.
```bash
# Vérifiez les points de montage actuels
df -h
```
---
<a id="R36"></a>
## R36-Modifier la valeur par défaut de UMASK
Pour modifier la valeur par défaut de UMASK sur un système GNU/Linux, suivez ces étapes en fonction des recommandations fournies :
1. Déterminer la configuration actuelle de UMASK :
Vérifiez la valeur actuelle de UMASK en exécutant la commande suivante dans le terminal :
```bash
umask
```
Notez la valeur actuelle, qui sera généralement quelque chose comme 0022.
2. Modifier la valeur par défaut dans /etc/profile pour les shells interactifs :
Ouvrez le fichier /etc/profile en tant qu'administrateur avec un éditeur de texte. Utilisez la commande suivante pour ouvrir le fichier avec l'éditeur nano, par exemple :
```bash
sudo nano /etc/profile
```
Ajoutez la ligne suivante à la fin du fichier pour définir la valeur par défaut de UMASK à 0077 :
```bash
umask 0077
```
Sauvegardez les modifications et quittez l'éditeur.
3. Modifier la valeur par défaut pour les services systemd :
Pour les services systemd, la valeur de UMASK peut être spécifiée dans le fichier de configuration du service.
```bash
sudo nano /etc/systemd/system/nom-du-service.service
```
Ajoutez la ligne suivante dans la section [Service] du fichier, si elle n'existe pas, ou modifiez la valeur existante :
```bash
UMask=0027
```
Sauvegardez les modifications et quittez l'éditeur.
4. Redémarrer les services :
Redémarrez les services qui nécessitent la nouvelle configuration pour que les changements prennent effet.
5. Vérifier les modifications :
Vérifiez que la nouvelle valeur de UMASK est active en exécutant à nouveau la commande :
```bash
umask
```
Assurez-vous que la nouvelle valeur est celle que vous avez configurée.
Ces étapes devraient vous permettre de modifier la valeur par défaut de UMASK conformément aux recommandations fournies.
---
<a id="R37"></a>
## R37-Utiliser des fonctionnalités de contrôle d'accès obligatoire MAC
***Type de mesure:*** Moindre privilège
Lorsque c’est possible, il est recommandé de ne pas monter automatiquement la partition /boot.
Dans tous les cas, l’accès au dossier /boot doit être uniquement autorisé pour l’utilisateur root.
Explorez la possibilité de combiner les fonctionnalités MAC avec des mécanismes de cloisonnement pour renforcer encore davantage la sécurité de votre système.
Assurez-vous que sudo est installé avec une configuration minimale et sécurisée.
Restreignez les droits d'exécution de sudo à un groupe d'utilisateurs dédiés pour réduire la surface d'attaque.
Modifiez les droits d'exécution de sudo pour permettre uniquement à un groupe spécifique d'utilisateurs d'y accéder. Cela réduit la surface d'attaque et diminue le risque d'exploitation par des utilisateurs non autorisés.
---
<a id="R38"></a>
## R38-Créer un groupe dédié à l'usage de sudo
***Type de mesure:*** Défense en profondeur
Il est essentiel de restreindre l'accès à la commande `sudo` en créant un groupe spécifique. Seuls les utilisateurs membres de ce groupe auront le droit d'exécuter des commandes avec `sudo`. La création d'un groupe dédié, tel que `sudogrp`, permet de renforcer la sécurité en limitant l'accès aux privilèges de superutilisateur.
**Implémentation :**
Suivez ces étapes pour mettre en œuvre cette règle :
1. **Création du Groupe dédié à sudo :**
- Utilisez la commande `addgroup` pour créer un groupe dédié, par exemple `sudogrp`.
```bash
sudo addgroup sudogrp
```
**Note :** Penser à installer sudo s'il n'est pas installé.
```bash
apt-get install sudo
```
2. **Attribution des Droits à sudo pour le Groupe :**
- Utilisez la commande `visudo` pour éditer le fichier `/etc/sudoers` de manière sécurisée.
```bash
sudo visudo
```
- Ajoutez la ligne suivante pour attribuer les droits de `sudo` au groupe `sudogrp`.
```plaintext
%sudogrp ALL=(ALL:ALL) ALL
```
**Note :** Il est important d'utiliser `visudo` pour éditer le fichier `sudoers` afin d'éviter des erreurs de syntaxe qui pourraient verrouiller l'accès à `sudo`.
3. **Vérification des Droits sur sudo :**
- Vérifiez les droits sur l'exécutable `sudo` pour vous assurer qu'ils sont corrects.
```bash
ls -al /usr/bin/sudo
```
:::info
*-rwsr-xr-x 1 root root 281624 27 juin 13:45 /usr/bin/sudo*
:::
- Assurez-vous que les droits incluent le groupe `sudogrp`.
4. **Vérification et Mise à Jour après une Mise à Jour de sudo :**
- Il est recommandé de vérifier les droits sur l'exécutable `sudo` après chaque mise à jour du paquet.
- Les droits peuvent être mis à jour automatiquement sur la plupart des gestionnaires de paquets.
Cette approche garantit que seuls les membres du groupe `sudogrp` auront le droit d'utiliser `sudo`. Il est essentiel de régulièrement vérifier et mettre à jour ces configurations, en particulier après des mises à jour du système ou du paquet `sudo`, pour maintenir un environnement sécurisé. La prudence lors de la modification du fichier `sudoers` est également soulignée, et la lecture de la documentation associée est fortement recommandée.
---
<a id="R41"></a>
## R41-Limiter l'utilisation de commandes nécessitant la directive EXEC
***Type de mesure:*** Moindre privilège
Les commandes nécessitant l’exécution de sous-processus, directive EXEC doivent être
explicitement listées et réduites autant que possible au strict minimum.
Spécifier des droits d’accès par négation, approche de type liste d’interdiction, est inefficace et peut être facilement contourné.
Voici comment vous pouvez la mettre en œuvre :
- Lister les directives EXEC nécessaires :
- Identifiez et documentez les sous-processus ou les commandes qui nécessitent explicitement l'exécution via la directive EXEC.
- Une fois que vous avez identifié ces sous-processus, assurez-vous qu'ils sont les seuls à être autorisés. Cela implique de mettre en place des politiques et des contrôles qui empêchent l'exécution de sous-processus non approuvés.
- Réduire au minimum les sous-processus autorisés :
- Évaluez chaque sous-processus listé pour déterminer s'il est absolument nécessaire.
- Revoyez régulièrement cette liste pour vous assurer qu'elle est toujours à jour et ne contient que les sous-processus indispensables.
---
<a id="R45"></a>
## R45-Activer les profils de sécurité AppArmor
***Type de mesure:*** Moindre privilège
La règle "Activer les profils de sécurité AppArmor" vise à garantir que les profils de sécurité fournis par AppArmor sont activés en mode "enforce" par défaut. AppArmor est un système de contrôle d'accès obligatoire (MAC) pour Linux qui restreint les capacités des programmes en utilisant des profils de sécurité.
**Implémentation :**
Suivez ces étapes pour mettre en œuvre cette règle :
1. **Vérifier si AppArmor est installé :**
```bash
sudo apt-get install apparmor
sudo apt-get install apparmor-utils
```
Une fois le package installé, vous devriez pouvoir utiliser la commande aa-enforce pour activer les profils AppArmor en mode "enforce". Assurez-vous également que le service AppArmor est en cours d'exécution :
```bash
sudo systemctl start apparmor
```
2. **Vérifier si AppArmor est actif :**
```bash
sudo aa-status
```
Assurez-vous que le module AppArmor est chargé et que des profils sont présents.
:::info
*apparmor module is loaded.
10 profiles are loaded.
10 profiles are in enforce mode.
/usr/bin/man
/usr/lib/NetworkManager/nm-dhcp-client.action
/usr/lib/NetworkManager/nm-dhcp-helper
/usr/lib/connman/scripts/dhclient-script
/{,usr/}sbin/dhclient
lsb_release
man_filter
man_groff
nvidia_modprobe
nvidia_modprobe//kmod
0 profiles are in complain mode.
0 profiles are in kill mode.
0 profiles are in unconfined mode.
1 processes have profiles defined.
1 processes are in enforce mode.
/usr/sbin/dhclient (551) /{,usr/}sbin/dhclient
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.
0 processes are in mixed mode.
0 processes are in kill mode.*
:::
3. **Activer tous les profils en mode "enforce" par défaut :**
```bash
sudo aa-enforce /etc/apparmor.d/*
```
Cette commande active le mode "enforce" pour tous les profils AppArmor disponibles.
4. **Vérifier les processus en mode "enforce" :**
```bash
sudo aa-status
```
Assurez-vous que les processus en cours d'exécution ont des profils définis et sont en mode "enforce".
5. **Redémarrer les services si nécessaire :**
Certains services peuvent nécessiter un redémarrage pour appliquer les changements AppArmor.
**Remarques :**
- Il est essentiel de tester attentivement les profils AppArmor avant de les activer en mode "enforce" sur un système en production pour éviter tout impact imprévu sur les applications.
- Certains systèmes peuvent avoir des exigences spécifiques en matière de profils AppArmor en fonction des applications installées.
En suivant ces étapes, vous devriez pouvoir activer les profils de sécurité AppArmor en mode "enforce" par défaut sur votre système Debian 12.
---
<a id="R51"></a>
## R51-Changer les secrets et droits d'accès dès l'installation
***Type de mesure:*** Moindre privilège
Tous les fichiers sensibles et ceux qui concourent aux mécanismes d’authentification doivent être mis en place dès l’installation du système. Si des secrets par défaut sont préconfigurés, ils doivent alors être remplacés pendant, ou juste après, la phase d’installation du système.
- Sécurisation des fichiers sensibles et mécanismes d'authentification :
Identification des fichiers sensibles : Avant l'installation du système, identifiez tous les fichiers sensibles, y compris ceux liés à l'authentification.
- Sécurisation lors de l'installation :
Assurez-vous que ces fichiers sont sécurisés dès l'installation du système.
- Remplacement des secrets par défaut :
Si votre système utilise des secrets (mots de passe, clés, etc.) préconfigurés, remplacez-les immédiatement pendant ou juste après la phase d'installation.
- Gestion des IPC (Inter-Process Communication) nommés, sockets ou pipes :
- Comprendre les différentes méthodes d'IPC : Les sockets réseau sont couramment utilisés pour la communication entre processus, mais pour la communication locale, vous pouvez utiliser des pipes ou des sockets Unix locaux.
- Sécurisation des sockets locaux : Lors de l'utilisation de sockets ou de pipes locaux, assurez-vous que les droits d'accès sont correctement définis. Ces droits peuvent dépendre du répertoire contenant la socket, plutôt que de la socket elle-même.
- Vérification de la conformité POSIX : Bien que certains systèmes d'exploitation respectent les permissions définies sur les sockets locales, la norme POSIX ne l'exige pas. Il est donc crucial de vérifier et de tester la conformité de votre système avec ces normes.
---
<a id="R57"></a>
## R57 - Éviter l'usage d'exécutables avec les droits spéciaux setuid
***Type de mesure:*** Défense en profondeur
Commencez par identifier tous les fichiers exécutables sur votre système qui ont les bits setuid ou setgid activés. Vous pouvez utiliser la commande suivante pour les trouver :
find / -perm /6000
Pour chaque fichier trouvé, déterminez s'il est nécessaire que le fichier ait les droits setuid ou setgid. Vérifiez si les fonctionnalités pour lesquelles ces fichiers sont utilisés nécessitent réellement ces permissions élevées.
Si un fichier n'a pas besoin de ces droits spéciaux, vous pouvez les retirer en utilisant la commande chmod. Par exemple, pour retirer setuid et setgid d'un fichier, utilisez :
chmod u-s,g-s /chemin/vers/le/fichier
---
<a id="R60"></a>
## R60 - Utiliser des dépôts de paquets durcis
***Type de mesure:*** Veille et maintenance
**Identifier les Dépôts de Confiance :**
Identifiez les dépôts officiels et de confiance fournis par la distribution Linux que vous utilisez. Ces dépôts sont généralement maintenus par les développeurs de la distribution et fournissent des paquets vérifiés.
**Privilégier les Paquets Durcis :**
Lorsque vous avez le choix entre plusieurs paquets fournissant le même service, privilégiez ceux qui font l'objet de mesures de durcissement. Ceci peut inclure des pratiques telles que la compilation avec des options de sécurité accrues, des configurations par défaut sécurisées, etc.
**Configurer Correctement les Miroirs de Dépôts :**
Si vous utilisez des miroirs de dépôts, assurez-vous qu'ils sont correctement configurés dans votre gestionnaire de paquets. Les miroirs doivent être des copies conformes des dépôts officiels et être régulièrement mis à jour.
<a id="R64"></a>
## R64 - Configurer les privilèges des services
***Type de mesure:*** Défense en profondeur
- Identification des services et exécutables : Il faut dresser une liste de tous les services et exécutables présents sur le système.
- Analyse des privilèges nécessaires : Pour chaque service et exécutable, il faut déterminez les privilèges nécessaires à leur fonctionnement.
- Évaluation des privilèges actuels : Comparer les privilèges actuellement accordés à chaque service ou exécutable avec ceux réellement nécessaires.
- Restriction des privilèges : Si des services ou des exécutables ont des privilèges plus élevés que nécessaires, réduisez-les au niveau approprié.
---
<a id="R65"></a>
## R65 - Cloisonner les services
***Type de mesure:*** Défense en profondeur
Pour mettre en place la recommandation de cloisonner les services en utilisant les mécanismes de confinement, de filtrage et d'isolation dans le noyau Linux, voici une approche étape par étape :
- Comprendre les Mécanismes de Sécurité Linux :
- **Namespaces** : Ils permettent d'isoler et de séparer les processus du système.
- **Cgroups** : Ils servent à limiter et à contrôler l'utilisation des ressources par les processus.
- **Linux Capabilities** : Ils permettent de diviser les privilèges des processus en un ensemble de capacités distinctes.
- **Seccomp** : Il permet de restreindre les appels système qu'un processus peut exécuter.
- Choisir le Type de Cloisonnement :
- **Par Conteneurs (LXC, Docker, Podman**) : Utilisez ces outils pour créer des conteneurs qui isolent les applications et leurs dépendances du reste du système.
- **Par Émulation (QEMU, VirtualBox)** : Utilisez ces émulateurs pour créer des machines virtuelles complètes, isolant ainsi complètement les systèmes d'exploitation.
- **Hyperviseur Léger ou Bare-Metal (Xen)** : Pour des environnements nécessitant une isolation forte entre les machines virtuelles.
- **Hyperviseur Noyau (Linux KVM)** : Intégré dans le noyau Linux, il offre une solution de virtualisation native.
- Mise en œuvre et Configuration :
- **Installation des Outils** : Installez les outils de cloisonnement choisis (Docker, Podman, QEMU, Xen, etc.).
- **Configuration** : Configurez chaque outil selon les besoins de sécurité et d'isolation. Par exemple, dans Docker, vous pouvez utiliser des fichiers Dockerfile pour définir l'environnement de chaque conteneur.
- Sécurisation des Conteneurs et des VMs :
- **Sécuriser le Noyau** : Assurez-vous que le noyau Linux est sécurisé, car une compromission du noyau affectera tous les conteneurs ou VMs.
- **Mises à jour Régulières** : Gardez le système, les conteneurs et les VMs à jour avec les derniers correctifs de sécurité.
- **Contrôle d'Accès** : Utilisez des politiques de contrôle d'accès pour limiter qui peut interagir avec les conteneurs et les VMs.
- **Audits et Logging** : Mettez en place des systèmes d'audit et de logging pour surveiller les activités et détecter les anomalies.
---
<a id="R71"></a>
## R71 - Mettre en place un système de journalisation
***Type de mesure:*** Veille et maintenance
- **Installation du Serveur Syslog** : Installez le serveur syslog de votre choix sur le système GNU/Linux. Vous pouvez le faire via le gestionnaire de paquets de votre distribution. Par exemple, pour installer rsyslog, vous pourriez utiliser une commande comme sudo apt-get install rsyslog.
- **Configuration du Serveur** : Configurez le serveur syslog pour collecter les événements des différents services et applications sur votre système. Cela implique de modifier les fichiers de configuration (/etc/syslog-ng/syslog-ng.conf pour syslog-ng ou /etc/rsyslog.conf et les fichiers dans /etc/rsyslog.d/ pour rsyslog) pour définir les règles de gestion des journaux, comme les sources d'information, les filtres, et les destinations des logs.
- **Sécurisation de la Communication** : Assurez-vous que la communication entre les clients et le serveur syslog est sécurisée.
- **Configuration des Clients** : Configurez la fonction syslog() de la glibc ou tout autre mécanisme de journalisation pour envoyer les logs au serveur syslog.
---
<a id="R72"></a>
## R72 - Mettre en place des journaux d'activité de service dédiés
***Type de mesure:*** Veille et maintenance
- Utilisation de la fonction syslog() :
- Cette fonction est utilisée dans les programmes C pour envoyer des messages au système de journalisation syslog.
- Vous devez inclure l'en-tête #include <syslog.h> dans votre code source.
- Utilisez la fonction syslog(int priority, const char *format, ...) pour envoyer des messages. Le paramètre priority détermine la gravité du message.
- Utilisation de la commande shell logger :
- logger est un outil en ligne de commande pour envoyer des messages au système syslog.
- Utilisez logger [options] [message] pour envoyer des messages personnalisés au journal système.
- Consultez la page de manuel (man logger) pour plus d'options et d'exemples d'utilisation.
- Configuration et utilisation du service auditd :
- auditd est un service de journalisation qui enregistre les activités du système basées sur des règles définies.
- Installez auditd si ce n'est pas déjà fait (sudo apt-get install auditd sur les distributions basées sur Debian).
- Configurez les règles de journalisation dans le fichier /etc/audit/audit.rules. Par exemple, vous pouvez définir des règles pour surveiller l'accès aux fichiers spécifiques, les appels système, etc.
- Redémarrez le service auditd pour appliquer les nouvelles règles (sudo systemctl restart auditd).
- Utilisez ausearch ou aureport pour interroger les logs d'audit.
---
<a id="R73"></a>
## R73 - Journaliser l'activité système avec auditd
***Type de mesure:*** Veille et maintenance
Sources:
https://docs.oracle.com/fr/learn/ol-auditd/#introduction
L'utilisation d'Auditd, le démon d'audit du noyau Linux, de surveiller les activités système, d'auditer les événements et de détecter des comportements suspects.
Les journaux générés par auditd peuvent devenir volumineux, surtout en présence d'un grand nombre d'activités enregistrées. Pour faciliter l'analyse, l'outil aureport offre la possibilité de sélectionner des informations pertinentes en se basant sur des critères spécifiques, tels que :
- Le contexte des échecs d'authentification,
- Les rapports d'événements liés à certains fichiers ou répertoires,
- Les événements anormaux, tels que des crashs logiciels ou des reconfigurations de cartes réseau.
**Configuration d'Auditd :**
Assurez-vous que le paquet auditd est installé sur votre système Debian 12.
- Éditer le fichier de configuration :
Ouvrez le fichier de configuration d'audit à l'aide d'un éditeur de texte, par exemple nano ou vim
```bash
sudo nano /etc/audit/auditd.conf
```
**Configurer les règles d'audit :**
Créez ou modifiez les règles d'audit dans le fichier /etc/audit/rules.d/audit.rules. Vous pouvez ajouter des règles pour surveiller des fichiers, des répertoires, des processus, etc. Par exemple, pour surveiller l'accès aux fichiers dans le répertoire /etc, vous pouvez ajouter la règle suivante :
```bash
-w /etc -p wa
```
Cela enregistrera les événements liés aux écritures et aux modifications (wa) dans le répertoire /etc.
**Consulter les journaux d'audit :**
Les journaux d'audit peuvent être consultés à l'aide de la commande ausearch ou aureport. Par exemple, pour afficher tous les événements dans les journaux d'audit, utilisez la commande :
```bash
sudo ausearch -m all
```
**Sauvegarde et rotation des journaux :**
on peut mettre un place une rotation des journaux pour éviter de remplir l'espace disque. Il faut modifier le fichier de configuration /etc/logrotate.conf et en ajoutant une entrée pour les journaux d'audit.
**Mise en œuvre d'une analyse des journaux :**
Configurez des outils ou des scripts pour analyser les journaux d'audit à la recherche d'activités suspectes ou d'événements de sécurité.
N'oubliez pas de consulter la documentation officielle d'Auditd et de personnaliser la configuration en fonction des besoins spécifiques de votre système et de vos exigences de sécurité.
---
<a id="R78"></a>
## R78 - Cloisonner les services réseau
***Type de mesure:*** Défense en profondeur
- Analyse et Planification :
- Évaluer les Services : Identifiez tous les services réseau existants et évaluez leurs besoins en termes de sécurité, accès, et ressources.
- Planification du Cloisonnement : Décidez comment cloisonner chaque service (par exemple, compte utilisateur dédié, conteneur, machine virtuelle ou physique).
-
- Mise en œuvre du Cloisonnement :
- Comptes Utilisateurs Dédiés : Créez des comptes utilisateurs spécifiques pour chaque service, avec des droits d'accès limités.
- Conteneurs : Utilisez des technologies de conteneurisation (comme Docker) pour isoler les services les uns des autres.
- Machines Virtuelles/Physiques : Déployez des services sur des machines virtuelles ou physiques distinctes pour un isolement maximal.
- Audit et Gestion des Droits d’Accès :
- Vérification des Droits : Effectuez un audit des droits d'accès pour s'assurer qu'ils sont correctement définis et limités aux besoins du service.
- Mise à jour Régulière : Révisez et mettez à jour les droits d'accès régulièrement pour maintenir la sécurité.
- Durcissement des Services :
- Mesures Techniques : Implémentez des mesures techniques pour sécuriser les services (par exemple, validation des entrées/sorties, configuration sécurisée).
- Conception et Maintenance : Intégrez des considérations de sécurité dès la phase de conception et continuez à les appliquer pendant la maintenance.
- Surveillance et Maintenance Continues :
- Surveillance : Mettez en place des systèmes de surveillance pour détecter toute activité suspecte ou tentative de compromission.
- Mises à Jour et Patchs : Assurez-vous que les services sont régulièrement mis à jour et que les patchs de sécurité sont appliqués.
Documentation et Formation :
Sign in with Wallet
Connect another wallet