Dans le chapitre précédent, nous avons vu les trois grands principes de sécurisation d'un système d'information. Il est temps de s'atteler à la tâche et de commencer l'audit de la machine.
Je vous propose ici de vérifier déjà trois points importants à propos du processus de démarrage de la machine :
la sécurité du bootloader ;
les options du noyau ;
le chargement dynamique des modules du noyau.
Vous pourrez constater que ces points illustrent notamment deux des trois principes de sécurisation d'un système d'exploitation.
Auditez le processus de démarrage et le bootloader
Appréhendez les risques liés à Grub
Sous Linux, en standard, le bootloader est la version 2 de Grub. Ce petit programme a notamment pour mission de lister les systèmes d'exploitation disponibles sur l'ordinateur à choisir, ou encore de lancer par défaut l'un de ces systèmes.
En réalité, ces deux choix concernent le même système (CentOS Linux avec un noyau 3.10), mais le second choix propose un mode de lancement dégradé, nommé rescue.
Et justement, Grub est un bootloader qui propose de nombreuses fonctionnalités à l'utilisateur. Il dispose même de son propre shell, qui vous permet d'interagir pendant le processus de démarrage et de modifier, entre autres, les options de lancement du noyau Linux. Ces fonctions sont certes très utiles, mais présentent par définition une faille de sécurité : toute personne qui se présenterait devant la machine et la redémarrerait pourrait alors accéder à ce shell et lancer le noyau avec des options, ce qui lui permettrait ensuite d'obtenir une invite de commande avec un compte privilégié.
Vérifiez les mesures de protection de Grub
Grub s'installe et se configure via des fichiers texte sous Linux. Le fichier principal est /boot/grub2/grub.cfg. Ce fichier est un condensé mis à jour de manière dynamique, à partir d'une arborescence située dans /etc/grub.d. Pour vérifier les mesures de protection, vous allez devoir lister dans un premier temps le contenu de cette arborescence :
[root@fichesproduits ~]# ls -lrtha /etc/grub.d/ total 84K -rw-r--r--. 1 root root 483 21 oct. 2017 README -rwxr-xr-x. 1 root root 216 21 oct. 2017 41_custom -rwxr-xr-x. 1 root root 214 21 oct. 2017 40_custom -rwxr-xr-x. 1 root root 11K 21 oct. 2017 30_os-prober -rwxr-xr-x. 1 root root 2,5K 21 oct. 2017 20_ppc_terminfo -rwxr-xr-x. 1 root root 11K 21 oct. 2017 20_linux_xen -rwxr-xr-x. 1 root root 11K 21 oct. 2017 10_linux -rwxr-xr-x. 1 root root 232 21 oct. 2017 01_users -rwxr-xr-x. 1 root root 8,5K 21 oct. 2017 00_header -rwxr-xr-x. 1 root root 1,1K 29 oct. 2017 00_tuned drwx------. 2 root root 182 27 mars 09:31 . drwxr-xr-x. 79 root root 8,0K 4 mai 13:56 ..
Les fichiers appartiennent bien à l'utilisateur root, cependant les droits associés sont trop permissifs.
La valeur 700 permet la lecture, l'écriture et l'exécution uniquement par le propriétaire.
Vous pouvez ainsi effectuer la modification de la valeur 700, par exemple avec la commande suivante :
chmod -R 700 /etc/grub.d
Dans cette arborescence, les fichiers numérotés de 10 à 40 servent principalement à configurer les propositions de démarrage présentées à l'utilisateur.
Le fichier 01_users est codifié pour contenir les informations d’authentification qui protègent l’accès au shell de Grub. Affichez le contenu de ce fichier :
[root@fichesproduits ~]# cat /etc/grub.d/01_users
#!/bin/sh -e
cat << EOF
if [ -f \${prefix}/user.cfg ]; then
source \${prefix}/user.cfg
if [ -n "\${GRUB2_PASSWORD}" ]; then
set superusers="root"
export superusers
password_pbkdf2 root \${GRUB2_PASSWORD}
fi
fi
EOF
[root@fichesproduits ~]#Le code contenu dans ce fichier propose de créer un utilisateur root avec les droits superusers ainsi qu'un mot de passe crypté en fonction d'un fichier ${prefix}/user.cfg, qui n'existe pas par défaut.
Vous pouvez protéger l'accès au shell de Grub avec le jeu de commandes suivant :
# Création du mot de passe chiffré [root@fichesproduits grub.d]# grub2-mkpasswd-pbkdf2 Entrez le mot de passe : Entrez de nouveau le mot de passe : Le hachage PBKDF2 du mot de passe est grub.pbkdf2.sha512.10000.5DE21A6C2CA01F7803AB4FD34AB04BA39586086C79EF7FDB5C359CDDBE08F80961193056539B1DE759F20AE5F46D6490F5BADD1BADB6AD9CC54C7B3FD4EC9667.69C5816F3468137EEDF393B9C08F109CE3DD7644CD2BA3CFAF5ECB5B95488AF0C26D7FC3F5B06E89C0F23B9576FE0275C96106ACD32B245ADF4EF38841D33BD0 [root@fichesproduits grub.d]# # Ajout de l'utilisateur admin dans le fichier 01_users : # vi /etc/grub.d/01_users set superusers="admin" password_pbkdf2 admin grub.pbkdf2.sha512.10000.5DE21A6C2CA01F7803AB4FD34AB04BA39586086C79EF7FDB5C359CDDBE08F80961193056539B1DE759F20AE5F46D6490F5BADD1BADB6AD9CC54C7B3FD4EC9667.69C5816F3468137EEDF393B9C08F109CE3DD7644CD2BA3CFAF5ECB5B95488AF0C26D7FC3F5B06E89C0F23B9576FE0275C96106ACD32B245ADF4EF38841D33BD0 # Mise à jour du fichier /boot/grub2/grub/cfg grub2-mkconfig -o /boot/grub2/grub.cfg
Grub2 permet une configuration assez fine de son processus de démarrage. Ainsi, en jouant sur les options pour chaque choix présenté à l'utilisateur, il est par exemple possible d'autoriser le démarrage d'une ligne uniquement à certains utilisateurs.
Vérifiez les options par défaut du noyau Linux
Suivez-moi dans cette vidéo guidée, ou retrouvez cette étape de l'audit rédigée ci-dessous.
Vous l'aurez maintenant compris, c'est Grub qui va lancer Linux via les fichiers contenus dans l'arborescence /etc/grub.d/.
Le fichier /boot/grub2/grub.cfg rassemble les fichiers contenus dans /etc/grub.d. Consultez ce fichier et relevez les options utilisées pour le lancement du noyau Linux à l'aide de la commande suivante :
grep linuz /boot/grub2/grub.cfg | head -1 linux16 /vmlinuz-3.10.0-862.el7.x86_64 root=/dev/mapper/centos_fichesproduits-root ro crashkernel=auto rd.lvm.lv=centos_fichesproduits/root rd.lvm.lv=centos_fichesproduits/swap rhgb quiet LANG=fr_FR.UTF-8
En plus des options liées au partitionnement LVM et de celles liées à la configuration des variables d'environnement (langue, encodage), deux options sont passées au noyau : rhgb et quiet. Ces deux options sont de l'ordre du confort pour l'utilisateur car elles présentent un écran graphique pendant le démarrage, cachant ainsi la plupart des messages du noyau pendant le processus.
Ces options sont configurées dans le fichier /etc/default/grub :
[root@fichesproduits grub.d]# cat /etc/default/grub GRUB_TIMEOUT=5 GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)" GRUB_DEFAULT=saved GRUB_DISABLE_SUBMENU=true GRUB_TERMINAL_OUTPUT="console" GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=centos_fichesproduits/root rd.lvm.lv=centos_fichesproduits/swap rhgb quiet" GRUB_DISABLE_RECOVERY="true" [root@fichesproduits grub.d]#
Dans le cadre de l'exploitation de systèmes virtualisés, il existe un service géré directement par le noyau Linux : IOMMU. Ce service permet de protéger la mémoire contre des accès non contrôlés, issus des périphériques du système. Par défaut, Linux gère IOMMU et va, selon le contexte, l'activer ou non. Il est recommandé de forcer l'activation de ce service en passant une option supplémentaire lors du démarrage du noyau.
Par exemple, en modifiant le fichier /etc/default/grub :
GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=centos_fichesproduits/root rd.lvm.lv=centos_fichesproduits/swap rhgb quiet iommu=force"
Vérifiez le blocage du chargement de modules Linux supplémentaire
L'aspect modulaire de Linux permet d'ajouter des fonctionnalités supplémentaires sous la forme de codes compilés à l'extérieur du code principal, qui se chargent de manière dynamique lors de l'exécution du noyau.
Cette fonctionnalité est très intéressante lorsqu'il s'agit de modéliser votre système d'exploitation, et donc d'ajouter ou de retirer à chaud un certain nombre de modules en fonction de vos besoins. Cependant, sur une machine d'exploitation, elle n'a plus de raison d'être et représente même une faille potentielle, car elle permet de modifier un noyau. Regardons cela ensemble en vidéo et dans le texte ci-après !
Vérifiez qu'il est possible de charger de manière dynamique de nouveaux modules sur le noyau actuel, via la commande suivante :
[root@fichesproduits ~]# sysctl kernel.modules_disabled kernel.modules_disabled = 0 [root@fichesproduits ~]#
Par défaut, cette variable est souvent positionnée à la valeur 0, ce qui autorise le chargement à chaud de modules supplémentaires dans le noyau.
Par exemple en passant les deux commandes suivantes :
# Modification du comportement pour l'exécution en cours [root@fichesproduits ~]# sysctl -w kernel.modules_disabled=1 kernel.modules_disabled = 1 # Prise en compte pour le prochain démarrage [root@fichesproduits ~]# echo "kernel.modules_disabled = 1" >> /etc/sysctl.conf
Bien entendu, ces deux opérations seront effectuées une fois que tous les modules nécessaires au bon fonctionnement du système et de ses services auront bien été chargés.
En résumé
À l'issue de cette première étape de l'audit du processus de démarrage, nous avons déjà émis quatre recommandations : deux d'une priorité critique, et deux autres d'une priorité moindre. Dans le prochain chapitre, je vous propose de nous pencher sur la connexion au serveur, notamment à travers les consoles virtuelles.
