• 20 heures
  • Moyenne

Ce cours est visible gratuitement en ligne.

course.header.alt.is_video

course.header.alt.is_certifying

J'ai tout compris !

Mis à jour le 28/11/2019

Auditez les comptes utilisateurs, les mots de passe, les droits spéciaux et les mises à jour de sécurité

Connectez-vous ou inscrivez-vous gratuitement pour bénéficier de toutes les fonctionnalités de ce cours !

 Dans le chapitre précédent, vous avez audité le partitionnement des disques, les options de montage des systèmes de fichiers ainsi que la partition /boot. Dans ce chapitre, nous allons auditer les comptes utilisateurs du système, les mots de passe associés et leurs droits par défaut, ainsi que les mises à jour de sécurité des packages de la distribution.

Auditez le processus de mot de passe

Sur Linux, le mot de passe est la donnée la plus sensible. Il permet d'authentifier ou de vérifier l'identité d'un compte utilisateur, et donc de bénéficier de ses droits sur le système. Les mots de passe sont gérés par la commande passwd et doivent s'appuyer sur le module PAM de Linux.

Vous pouvez suivre la vidéo et vous appuyer sur la version texte avec les commandes ci-après.

Lancez la commande suivante :

[root@fichesproduits ~]# ldd /bin/passwd | grep pam
libpam.so.0 => /lib64/libpam.so.0 (0x00007f84fd844000)
libpam_misc.so.0 => /lib64/libpam_misc.so.0 (0x00007f84fd640000)
[root@fichesproduits ~]#

C'est le module PAM qui est responsable du stockage chiffré des mots de passe sur le système de fichiers. Historiquement, le fichier /etc/passwd contenait la liste des utilisateurs ET leurs mots de passe. Or ce fichier est accessible à tout le monde en lecture seule, ce qui permet à un attaquant d'en faire une copie et de déchiffrer les mots de passe. Désormais, Linux utilise le principe de mots de passe dits « shadow ». Ces mots de passe figurent dans un fichier /etc/shadow, lisible uniquement par root.

Pour tout savoir sur les mots de passe shadow de Linux, rendez-vous sur cette documentation (en français !).

Par exemple, avec la commande suivante :

[root@fichesproduits ~]# grep shadow /etc/pam.d/*
/etc/pam.d/password-auth:password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok
/etc/pam.d/password-auth-ac:password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok
/etc/pam.d/system-auth:password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok
/etc/pam.d/system-auth-ac:password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok

Le module PAM garantit aussi un minimum de robustesse des mots de passe. La librairie qui vérifie la robustesse des mots de passe est pam_pwquality.so :

[root@fichesproduits ~]# grep pam_pwquality /etc/pam.d/*
/etc/pam.d/password-auth:password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
/etc/pam.d/password-auth-ac:password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
/etc/pam.d/system-auth:password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
/etc/pam.d/system-auth-ac:password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
[root@fichesproduits ~]#

Pour assurer la robustesse des mots de passe, il est possible de changer les valeurs par défaut du module pam_pwquality.

Vous pouvez voir la configuration du module pam_pwquality dans le fichier /etc/security/pwquality.conf. Celle-ci peut être par exemple : 

Configuration

Description

Valeur par défaut

difok

Nombre de caractères dans le nouveau mot de passe, qui ne doivent pas être présents dans l'ancien

5

minlen

Longueur minimale

9 (>6 obligatoire)

ucredit

Nombre de majuscules

1

lcredit

Nombre de minuscules

1

dcredit

Nombre de chiffres

1

ocredit

Nombre de caractère non alphanumériques

1

maxrepeat

Nombre maximal de caractères se répétant

0 (désactivé)

Auditez les comptes utilisateurs et leur mot de passe

Regardons ensemble comment auditer les comptes utilisateurs et leur mot de passe en vidéo, puis dans la version texte ci-dessous. 

Comme évoqué précédemment, le fichier contenant les utilisateurs du système est /etc/passwd.

[root@fichesproduits ~]# cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
...
marketing:x:1000:1000:marketing:/home/marketing:/bin/bash
patrick:x:1001:1001::/home/patrick:/bin/bash
stephanie:x:1002:1002::/home/stephanie:/bin/bash
christophe:x:1003:1003::/home/christophe:/bin/bash
apache:x:48:48:Apache:/usr/share/httpd:/sbin/nologin
mysql:x:27:27:MariaDB Server:/var/lib/mysql:/sbin/nologin

Le dernier champ de ce fichier indique notamment le shell à exécuter lorsqu'un l'utilisateur se connecte sur une console ou un terminal distant. Si ce champ indique /sbin/nologin, le shell exécuté renverra simplement un message d'erreur à l'utilisateur. Ainsi, il est déjà possible de filtrer les comptes qui peuvent se connecter, grâce à la commande suivante :

[root@fichesproduits ~]# cat /etc/passwd | grep -v nologin
root:x:0:0:root:/root:/bin/bash
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
marketing:x:1000:1000:marketing:/home/marketing:/bin/bash
patrick:x:1001:1001::/home/patrick:/bin/bash
stephanie:x:1002:1002::/home/stephanie:/bin/bash
christophe:x:1003:1003::/home/christophe:/bin/bash
[root@fichesproduits ~]#

Nous retrouvons ici les comptes système sync, shutdown et halt que l'on peut ignorer, les quatre comptes utilisateurs marketingpatrickstephanie et christophe, et enfin le compte root.

Considérons que les quatre comptes utilisateurs sont configurés de la même façon et prenons l'exemple de stephanie.

Pour obtenir les informations sur le mot de passe du compte stephanie, lancez la commande chage :

[root@fichesproduits ~]# chage -l stephanie
Dernier changement de mot de passe : mars 27, 2019
Fin de validité du mot de passe : jamais
Mot de passe désactivé : jamais
Fin de validité du compte : jamais
Nombre minimum de jours entre les changements de mot de passe : 0
Nombre maximum de jours entre les changements de mot de passe : 99999
Nombre de jours d'avertissement avant la fin de validité du mot de passe : 7
[root@fichesproduits ~]#

Nous obtenons ici un exemple typique de configuration par défaut, où l'utilisateur n'est pas forcé de changer son mot de passe.

Par exemple, avec la commande suivante :

[root@fichesproduits ~]# chage -m 7 -M 90 -W 10 stephanie
[root@fichesproduits ~]#
[root@fichesproduits ~]# chage -l stephanie
Dernier changement de mot de passe : mars 27, 2019
Fin de validité du mot de passe : juin 25, 2019
Mot de passe désactivé : jamais
Fin de validité du compte : jamais
Nombre minimum de jours entre les changements de mot de passe : 7
Nombre maximum de jours entre les changements de mot de passe : 90
Nombre de jours d'avertissement avant la fin de validité du mot de passe : 10

Il est possible de modifier les valeurs par défaut pour la gestion des mots de passe dans le fichier /etc/login.defs, ce qui est pratique si l'administrateur système doit créer des comptes utilisateurs supplémentaires.

[root@fichesproduits ~]# cat /etc/login.defs | grep PASS
# PASS_MAX_DAYS Maximum number of days a password may be used.
# PASS_MIN_DAYS Minimum number of days allowed between password changes.
# PASS_MIN_LEN Minimum acceptable password length.
# PASS_WARN_AGE Number of days warning given before a password expires.
PASS_MAX_DAYS 99999
PASS_MIN_DAYS 0
PASS_MIN_LEN 5
PASS_WARN_AGE 7
[root@fichesproduits ~]#

Par exemple ici, la période de validité du mot de passe est infinie par défaut. Il serait nécessaire au moins de modifier la valeur de la directive PASS_MAX_DAYS à 90.

Listez les fichiers, avec les attributs setuid, setgid et stickybit

Prenez justement l'exemple de la commande passwd :

[root@fichesproduits ~]# ls -lrtha /bin/passwd
-rwsr-xr-x. 1 root root 28K 10 juin 2014 /bin/passwd
[root@fichesproduits ~]#

Cette commande utilise ici setuid pour permettre à un utilisateur de la lancer avec le compte propriétaire de la commande (root). C'est indispensable pour obtenir les privilèges nécessaires pour modifier le fichier /etc/shadow, car seul le compte root peut le faire.

[root@fichesproduits ~]# ls -lrth /etc/shadow
---------- 1 root root 1,2K 5 mai 19:13 /etc/shadow
[root@fichesproduits ~]#

Les fichiers disposant du droit setuid sont donc très sensibles et doivent être vérifiés par l'administrateur. En effet, les commandes associées sont spécialement conçues pour utiliser ce droit et, par conséquent, toute commande non vérifiée peut provoquer des attributions de privilèges interdites.

Par exemple, avec les commandes suivantes :

## Les fichiers setuid
[root@fichesproduits ~]# find / -type f -perm /4000 -ls 2>/dev/null
12849314 24 -rws--x--x 1 root root 24048 avril 11 2018 /usr/bin/chfn
12849317 24 -rws--x--x 1 root root 23960 avril 11 2018 /usr/bin/chsh
...
13008451 140 ---s--x--x 1 root root 143184 avril 11 2018 /usr/bin/sudo
...
12897991 16 -rwsr-xr-x 1 root root 15432 avril 11 2018 /usr/lib/polkit-1/polkit-agent-helper-1
12879166 60 -rwsr-x--- 1 root dbus 58016 avril 11 2018 /usr/libexec/dbus-1/dbus-daemon-launch-helper

## Les fichiers setgid
[root@fichesproduits ~]# find / -type f -perm /6000 -ls 2>/dev/null
12638690 16 -r-xr-sr-x 1 root tty 15344 juin 10 2014 /usr/bin/wall
12849314 24 -rws--x--x 1 root root 24048 avril 11 2018 /usr/bin/chfn
12849317 24 -rws--x--x 1 root root 23960 avril 11 2018 /usr/bin/chsh
...
271691 460 ---x--s--x 1 root ssh_keys 469880 avril 11 2018 /usr/libexec/openssh/ssh-keysign

## Les répertoires stickybit
[root@fichesproduits ~]# find / -type d -perm -1000 -exec ls -ld {} \;
drwxrwxrwt 2 root root 40 5 mai 12:23 /dev/mqueue
drwxrwxrwt 2 root root 40 5 mai 12:23 /dev/shm
...
drwxrwxrwt 2 root root 6 5 mai 12:23 /tmp/systemd-private-857d97fdb38348769fb88204ce6007f3-mariadb.service-GrLeTT/tmp
[root@fichesproduits ~]#

Auditez le processus sudo

Lors de l'audit des comptes utilisateurs, nous avons pu remarquer que seul le compte qui disposait des privilèges administrateur root semblait exister. Cette configuration par défaut n'est pas acceptable : chaque administrateur de la machine doit être clairement identifié et le groupe auquel il appartient doit disposer des droits d'administration, afin de permettre une meilleure traçabilité des opérations privilégiées effectuées sur le serveur. L'utilisateur root ne doit être utilisé qu'en dernier recours.

Par exemple, avec la commande suivante :

groupadd admin

Parmi les fichiers disposant du droit setuid, nous avons pu observer la présence de /usr/bin/sudo.

Cet outil est un gestionnaire de contrôle d'accès qui permet à un utilisateur d'obtenir des droits prédéfinis dans le fichier de configuration /etc/sudoers.

Analysons de plus près cette commande :

[root@fichesproduits ~]# ls -lrtha /usr/bin/sudo
---s--x--x. 1 root root 140K 11 avril 2018 /usr/bin/sudo
[root@fichesproduits ~]#

Elle dispose bien du bit setuid, mais est configurée par défaut avec les droits d'exécution pour tout utilisateur. Cette configuration n'est pas sécurisée et il est nécessaire de restreindre le droit d'exécution de cette commande, notamment au groupe administrateur créé précédemment.

Par exemple, avec la commande suivante :

[root@fichesproduits ~]# chmod 4750 /usr/bin/sudo
[root@fichesproduits ~]# chown root:admin /usr/bin/sudo
[root@fichesproduits ~]# ls -lrtha /usr/bin/sudo
-rwsr-x---. 1 root admin 140K 11 avril 2018 /usr/bin/sudo
[root@fichesproduits ~]#

Ensuite, il est nécessaire de vérifier que le groupe admin dispose bien au minimum des droits pour exécuter les commandes nécessaires au maintien du système dans le fichier /etc/sudoers. Au mieux, toutes les commandes possibles.

Par exemple :

%admin ALL=(ALL) ALL

Relevez les mises à jour de sécurité

Les distributions fournissent le système sous la forme de packages de sources précompilées. Cette fonctionnalité très pratique nous permet d'éviter de devoir compiler manuellement les composants du système. Cependant, il faut toujours vérifier que les éditeurs de distributions n'ont pas mis à jour un package suite à la publication d'une CVE (Common Vulnerabilities Exposure). Pour effectuer cette veille de façon correcte, il faut s'assurer que les dépôts de packages interrogés sont qualifiés et sûrs.

Pour cela, il faut vérifier, dans les fichiers de configuration du package manager (ici yum), que les adresses des dépôts pointent vers des serveurs maintenus directement par l'éditeur, et que les packages téléchargés comportent une signature numérique.

Par exemple, en consultant le fichier /etc/yum.repos.d/CentOS-Base.repo :

[root@fichesproduits ~]# more /etc/yum.repos.d/CentOS-Base.repo
# CentOS-Base.repo
...
[base]
name=CentOS-$releasever - Base
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os&infra=$infra
#baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7

Ici, les attributs gpgcheck et gpgkey garantissent que toutes les signatures numériques des packages téléchargés seront vérifiées.

Il faut aussi constamment vérifier qu'il n'y a pas besoin de mettre à jour des packages qui auraient été corrigés par l'éditeur. Pour cela, il faut installer un plugin permettant de mettre à jour uniquement les packages corrigés pour des raisons de sécurité : yum-plugin-security.

Pour voir si ce plugin est installé, lancez la commande suivante :

[root@fichesproduits ~]# yum list installed | grep security
[root@fichesproduits ~]#

Si la commande ne renvoie aucun résultat, c'est que le plugin n'est pas installé.

Par exemple, avec la commande suivante :

yum install yum-plugin-security

La commande yum --security check-update regarde s'il y a besoin de mettre à jour des packages :

[root@fichesproduits ~]# yum --security check-update
Modules complémentaires chargés : fastestmirror
base/7/x86_64 | 3.6 kB 00:00:00
epel/x86_64/metalink | 24 kB 00:00:00
epel/x86_64
...
--> 1:openssl-1.0.2k-16.el7_6.1.x86_64 from updates excluded (updateinfo)
--> 1:openssl-devel-1.0.2k-16.el7_6.1.i686 from updates excluded (updateinfo)
No packages needed for security; 165 packages available

Ici, le retour de cette commande nous indique qu'il n'y a pas besoin de mettre à jour des packages corrigés pour des raisons de sécurité (mais que 165 packages peuvent toutefois être mis à jour).

Cette vérification doit être effectuée très régulièrement (1 fois par jour par exemple), notamment sur les serveurs accessibles publiquement. Il est donc nécessaire de planifier une tâche automatique qui mettra à jour les packages corrigés pour des raisons de sécurité. Sur CentOS, c'est le package yum-cron qui se charge de ces mises à jour, en s'appuyant sur le gestionnaire de tâches planifiées cron.

Par exemple, avec la commande suivante :

yum install yum-cron

Cette commande va programmer une tâche quotidienne avec la configuration suivante :

[root@fichesproduits ~]# grep ^[^#] /etc/yum/yum-cron.conf
[commands]
update_cmd = default
update_messages = yes
download_updates = yes
apply_updates = no
random_sleep = 360
[emitters]
system_name = None
emit_via = stdio
output_width = 80
[email]
email_from = root@localhost
email_to = root
email_host = localhost
[groups]
group_list = None
group_package_types = mandatory, default
[base]
debuglevel = -2
mdpolicy = group:main

La directive update_cmd peut être positionnée aux valeurs suivantes :

Valeur

Commande correspondante

update_cmd = default

yum upgrade

update_cmd = security

yum --security upgrade

update_cmd = security-severity:Critical

yum --sec-severity=Critical upgrade

update_cmd = minimal

yum --bugfix update-minimal

update_cmd = minimal-security

yum --security update-minimal

update_cmd = minimal-security-severity:Critical

--sec-severity=Critical update-minimal

En résumé

Auditer les comptes utilisateurs et les mises à jour de sécurité des packages des distributions est un travail conséquent. Il nous a permis de proposer pas moins de 11 recommandations. Certaines ne sont que de simples vérifications de paramétrages, souvent corrects par défaut, d'autres relèvent tout de même de vraies lacunes dans la configuration initiale du système. Dans la quatrième partie de ce cours, je vous propose de nous intéresser de plus près aux services exécutés de manière nécessaire sur le serveur, afin de vérifier qu'ils sont configurés correctement.

Résumé des recommandations pour cette partie

Recommandation

Type

Principe

Vérifier que le CPU dispose bien des flags PAE et NX

CRITICAL

Défense en profondeur

Vérifier la présence d'un minimum de mémoire SWAP sur le système

WARNING

Défense en profondeur

Vérifier le chiffrement des partitions sensibles du système

CRITICAL

Défense en profondeur

Vérifier que le partitionnement isole et protège les composants du système

CRITICAL

Défense en profondeur

Vérifier les options des points de montage des systèmes de fichiers

CRITICAL

Moindre privilège

Vérifier la protection de la partition /boot

CRITICAL

Moindre privilège

Vérifier que les mots de passe du module PAM sont en mode shadow

CRITICAL

Défense en profondeur

Vérifier la robustesse des mots de passe avec le module pam_pwquality

WARNING

Défense en profondeur

Vérifier que les comptes utilisateurs qui peuvent se connecter ont pour obligation de changer leur mot de passe régulièrement

CRITICAL

Défense en profondeur

Vérifier les valeurs par défaut des attributs des mots de passe pour chaque compte utilisateur dans /etc/login.defs

WARNING

Défense en profondeur

Examiner la liste des fichiers avec les droits spéciaux setuid, setgid et sticky bit

CRITICAL

Moindre privilège

Vérifier la présence d'un groupe d'utilisateurs identifié comme administrateur de la machine et disposant des droits de changement de privilèges par l'intermédiaire d'un processus type sudo

CRITICAL

Moindre privilège

Vérifier que la commande sudo peut être exécutée uniquement par le groupe administrateur (+ root)

CRITICAL

Moindre privilège

Vérifier que le fichier de configuration /etc/sudoers contient la déclaration des commandes nécessaires au maintien du système pour les utilisateurs du groupe administrateur

CRITICAL

Moindre privilège

Vérifier que les packages installés sur le système sont signés et sûrs

CRITICAL

Défense en profondeur

Vérifier que le plugin gérant les mises à jour de sécurité des packages de la distribution est bien installé

CRITICAL

Défense en profondeur

Vérifier la planification régulière d'une tâche automatique pour mettre à jour les packages corrigés pour raisons de sécurité

CRITICAL

Défense en profondeur

Maintenant que vous avez vu en détail l'audit du système, je vous propose de nous pencher sur les services dans la partie suivante !

Exemple de certificat de réussite
Exemple de certificat de réussite