Le chapitre précédent vous a montré comment sécuriser le processus de démarrage de Linux avec le bootloader et les options du noyau.
Dans ce chapitre, je vous propose de vous intéresser aux consoles virtuelles, qui sont les premiers éléments d'interaction avec l'utilisateur après le processus de démarrage. Vous verrez notamment comment vérifier que la connexion root est empêchée par défaut depuis ces consoles, ou encore comment vérifier que le processus de connexion résiste à une attaque par dictionnaire. Enfin, je vous indiquerai comment redémarrer le serveur à partir des raccourcis clavier Ctrl+Alt+Fn.
Auditez les accès aux consoles virtuelles
Ces consoles sont accessibles à l'aide de la combinaison de touches Ctrl+Alt+Fn, où n représente le numéro de la console à afficher à l'écran. Linux propose par défaut sept consoles virtuelles, de F1 à F7. Traditionnellement, les six premières proposent un terminal en mode texte, alors que la septième (déplacée à la première depuis quelques temps déjà) propose éventuellement d'exécuter le système de fenêtre graphique (X Windows System).
Les consoles proposant un terminal en mode texte exécutent une tache getty, qui lance en boucle le processus /bin/login permettant d'afficher le prompt de connexion à l'utilisateur.
Ces consoles étant accessibles à toute personne disposant d'un accès physique à la machine sur son site d'installation, elles représentent une faille potentielle de sécurité.
Sous Linux, la gestion de la connexion console est gérée par le module PAM (Pluggable Authentication Module). La configuration de ce module est située dans l'arborescence /etc/pam.d/
Vous pouvez examiner la configuration actuelle du module avec la commande suivante :
[root@fichesproduits ~]# grep "^[^#;]" /etc/pam.d/login auth [user_unknown=ignore success=ok ignore=ignore default=bad] pam_securetty.so auth substack system-auth auth include postlogin account required pam_nologin.so account include system-auth password include system-auth session required pam_selinux.so close session required pam_loginuid.so session optional pam_console.so session required pam_selinux.so open session required pam_namespace.so session optional pam_keyinit.so force revoke session include system-auth session include postlogin -session optional pam_ck_connector.so
Vous constaterez que le processus exploite le module pam_securetty.so. Ce module s'appuie notamment sur le fichier de configuration /etc/securetty. Vous pouvez lister le contenu de ce fichier avec la commande suivante :
[root@fichesproduits ~]# cat /etc/securetty console vc/1 vc/2 ... ... hvsi1 hvsi2 xvc0 [root@fichesproduits ~]#
Ce fichier contient la liste des terminaux sous la forme de périphériques (sans le /dev/), autorisant la connexion de l'utilisateur root. De nombreux terminaux autorisent cette connexion par défaut. La configuration actuelle présente donc une faille de sécurité.
Par exemple, via la commande suivante :
echo > /etc/securetty
Cette action empêche la connexion directe de l'utilisateur root depuis une console virtuelle. Mais il est tout à fait possible de se connecter avec un utilisateur moins privilégié pour ensuite passer sous l'utilisateur root avec la commande su.
La seconde ligne du fichier /etc/pam.d/login indique qu'un autre fichier est utilisé pour gérer le processus de connexion, notamment /etc/pam.d/system-auth. Listez le contenu de ce fichier avec la commande suivante :
[root@fichesproduits ~]# cat /etc/pam.d/system-auth #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth required pam_faildelay.so delay=2000000 auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 1000 quiet_success auth required pam_deny.so account required pam_unix.so account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 1000 quiet account required pam_permit.so password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type= password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so -session optional pam_systemd.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so
À nouveau, de nombreux modules entrent en jeu lors du processus d'authentification. Le module pam_faildelay.so (deuxième ligne du fichier ci-dessus) est intéressant car il permet de définir l'intervalle minimal de temps entre chaque tentative de connexion. Celui-ci est mesuré en millisecondes. La valeur par défaut, positionnée ici à 2 secondes, peut convenir à la majorité des contextes opérationnels.
Un robot essayant de se connecter sur une des consoles virtuelles de la machine devra patienter 5 ou 10 secondes entre chaque tentative, ce qui permet de ralentir le rythme des attaques.
Empêchez le Ctrl+Alt+Supp fatidique
Linux est le descendant d'une longue lignée de systèmes d'exploitation. Chez son grand-père UNIX, l'opérateur pouvait lancer des commandes particulières avec une combinaison de touches sur le clavier de la console. Ces combinaisons de touches étaient nommées Secure Attention Key (SAK), ou Magic System Request Key.
La combinaison Ctrl+Alt+Supp est un héritage des anciennes SAK. À l'époque, elle permettait à l'opérateur qui prenait la station de garantir un prompt initial sans usurpation d'identité. Aujourd'hui, cette combinaison de touches se traduit le plus souvent par un ordre de redémarrage de la machine ! Toute personne pouvant accéder au clavier peut redémarrer la machine avec cette combinaison de touches, ce qui n'est pas acceptable.
Par exemple, en passant la commande suivante :
ln -sf /dev/null /etc/systemd/system/ctrl-alt-del.target
Nous reviendrons plus en détail sur cette notion de fichier target (cible) dans le prochain chapitre.
Par exemple, avec la commande suivante :
# Pour l'exécution courante sysctl -w kernel.sysrq = 0 # Pour prise en compte au prochain démarrage echo "kernel.sysrq=0" >> /etc/sysctl.conf
Vous pouvez aussi recompiler votre noyau sans les combinaisons associées. Vous trouverez les fichiers noyau concernés ici : https://github.com/torvalds/linux/blob/master/drivers/tty/sysrq.c. Notez que la structure associée débute à la ligne 430. Il s'agit de :
static struct sysrq_key_op *sysrq_key_table[36] = {
&sysrq_loglevel_op, /* 0 */
&sysrq_loglevel_op, /* 1 */
&sysrq_loglevel_op, /* 2 */
...En résumé
Cette deuxième étape vous a permis d'établir quatre nouvelles recommandations liées au principe de défense en profondeur : retarder l'accès aux privilèges lorsqu'un attaquant réussit à approcher physiquement à la machine. Deux recommandations de priorité critique et deux d'une priorité moindre ont permis d'aborder le processus de connexion aux consoles virtuelles du système et les combinaisons de touches au clavier. Dans le prochain chapitre, nous nous pencherons sur le dernier aspect, lié au démarrage du système : l'audit des services et processus lancés automatiquement avec la machine.
