Auditez la sécurité d'un système d'exploitation

 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 : 

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 marketing, patrick, stephanie 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 :

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

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 !