L’authentification est devenue au cours de ces dernières années un vrai sujet. L’évolution des nouvelles technologies et de ces usages ne cessent de revoir perpétuellement son fonctionnement afin de garantir sécurité et facilité d’utilisation.

Aujourd’hui, un grand nombre de site si ce n’est la quasi-totalité proposent la mise en place à ces usagers l’authentification multifactoriel (MFA) et ce à travers différents biais, mail, sms, authenticator, clé physique ect.

Depuis quelques années déjà je me suis interrogé sur la mise en place d’une telle fonctionnalité sur les environnements UNIX que je trouvais trop exposés et vulnérables.

LINUX, vulnérable ? et Windows alors t’en fait quoi pèpère ?

A cette époque j’avais 20 ans disait la chanson et il était plus facile (c’est toujours d’actualité), de déployer un petite VM LINUX avec un daemon configuré pour publier un service (xFTPx, Serveur WEB perso ect) que de monter une grosse VM Windows avec des applications tierces et une configuration chronophage. Toutefois, je laisse à chacun le choix des solutions et ne souhaite pas engager le sujet Est-ce que Linux est mieux que Windows t-elle est la question. Quelqu’un de constitution normal ne se poserait pas la question quant à la publication du protocole SSH directement sur le WWW (ou autres services à risques) de manière frontale.

Et pourtant bien qu’en 2024 il subsiste toujours ce type de publication sans Firewall, sans durcissement du système d’exploitation et sans renforcement de l’authentification sur le WWW. Dans le cas contraire, même à travers un firewall le risque subsiste.

La question bien avant d’aborder le durcissement d’un environnement LINUX dans un environnement ISO27001/HDS est donc de limiter le risque lié à l’authentification de base Login/Password.

Les puristes me diront que la MFA existe depuis longtemps à travers l’authentification par clé (privée, publique) et par passphrase. Je vois cette méthode d’authentification différemment.

Effectivement, si je ne possède pas la clé privée pas possible de m’authentifier via SSH. Donc cela répond à la MFA. Toutefois, il faut stocker la clé dans un endroit sécurisé, ne pas la perdre, ne pas se la faire voler. Ne pas l’avoir déployée sur une armada d’autres serveurs (pratique courante dans l’administration des systèmes d’informations pour faciliter le MCO).

« La sécurité ce n’est pas pratique » disait l’un de mes collègues et il a malheureusement bien raison. Je suis partisan des relation 1:1 soit d’un jeu de clé par serveur.

Pour cela je préfère donc les méthodes d’authentifications suivantes uniquement pour les comptes utilisateurs :

Login + MFA
Key + MFA

Rien ne justifie l’authentification direct par le biais d’un compte avec privilège, administrateur ou root. La notion d’escalade de privilège et donc de RBAC ferra l’objet d’un autre billet.

Prérequis

SE: RHEL, DEBIAN, UBUNTU
Apps: Google-Authenticator
Autres: Sauvegarde fonctionnelle et/ou sauvegarde des fichiers de configurations au préalable

MFA – Google Authentificator

Installation

Rechercher et installer les paquets suivants, google authenticator et qrencode-libs.

Le premier paquet permettra de générer les tokens de connexion toutes les 30 secondes
Le second paquet permettra de générer le QRCode pour intégrer le code dans un gestionnaire d’authentification.

$ sudo dnf search google-authenticator 
$ sudo dnf search qrencode-libs
$ sudo dnf install google-authenticator qrencode-libs

Configuration

Pour la phase de configuration, la majorité des actions sont à réaliser en tant qu’utilisateur et non en tant que root.

/!\Attention : Pour rappel, les commandes en tant qu’utilisateur seront signalées avec $ et avec # en tant que root.

Création d’un répertoire caché .ssh dans le home de l’utilisateur

$ mkdir ~/.ssh

Ce répertoire contiendra le fichier d’authentification propre à l’utilisateur avec les tokens générés par Google Authentificator. Cette manipulation permet de ne pas désactiver le SELinux. Ce service n’autorise pas par défaut le daemon SSHD à écrire en dehors de son répertoire dans le home des utilisateurs, c’est pourquoi nous allons configurer l’application google-authentication pour changer d’emplacement par défaut.

$ google-authentication -s ~/.ssh/google_authenticator

Si tu veux du challenge pour me « tipiaker » tu peux y aller à savoir que :

La VM n’est pas publiée
La VM est jetable c’est du LAB
La VM est sur mon poste et pas sur une infrastructure de production
La VM a été reconfiguré plusieurs fois
J’ai un doctorat en paint obtenu sur Windows 95 (True story pour le SE et paint)

Une fois la configuration effectuée, réactualiser le contexte du daemon SSH dans le SELinux

$ restorecon -rv ~/.ssh/

SSH & 2FA

Avant de commencer, faite une sauvegarde des fichiers de configuration suivant (sshd et sshd_config).

$ sudo cp /etc/pam.d/sshd /etc/pam.d/sshd.origin
$ sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.origin

Modifiez le fichier de configuration sshd et ajouter les lignes suivantes à la fin du fichier.

$ sudo vim /etc/pam.d/sshd

auth       required     pam_google_authenticator.so secret=/home/${USER}/.ssh/google_authenticator 
auth       required     pam_permit.so

Comme nous avons modifié l’emplacement par défaut de l’apps google_authenticator, nous spécifions l’emplacement du fichier de configuration dans le home de l’utilisateur. L’avantage de cette méthode, nous pouvons générer un nouveau fichier MFA pour d’autres utilisateurs vus que le chemin appel la variable d’environnement ${USER}.
Afin de rendre optionnel la méthode d’authentification, nous pouvons préciser à la fin de la première ligne l’argument nullok.
La seconde ligne permet d’autoriser l’authentification si un utilisateur n’utilise pas la MFA dans le cas de l’utilisation nullok.

Modifiez le fichier de configuration du daemon ssh pour activer le challenge d’authentification en passant ce dernier à YES et en vérifiant que l’argument UsePAM est à YES également.

Sauvegardez le fichier.

/!\Attention : Depuis RHEL 9 la configuration est différente pour l’authentification google.
Il est donc nécessaire de spécifier le challenge d’authentification dans le fichier gauth.conf.

$ echo "ChallengeResponseAuthentication yes" > /etc/ssh/sshd_config.d/10-gauth.conf

Relancez le daemon SSH sans quitter le terminal.

$ sudo systemctl restart sshd.service

Test

Dans un second terminal, connectez vous en tant qu’utilisateur protégé par la MFA.
Saisissez le mot de passe local de l’utilisateur, puis saisissiez le TOTP.

Vous voilà authentifiés.

Conclusion

L’accès à la ressource est sécurisé via SSH ainsi que par une authentification complémentaire. Nous pouvons toujours en cas d’incident passer par l’authentification classique depuis la console système. Toutefois nous pouvons noter une limite à l’implémentation de cette fonctionnalité.

Si perte de la MFA possible de récupérer la clé par la console système
Double sécurité
Peut être couplé avec d’autres restrictions
Possibilité de mettre facultatif l’authentification double facteurs
Modification rapide du jeton d’authentification

Pas pris en charge par toutes les solutions tierces ni éditeurs (Nécessite de désactiver l’authentification)
Pour des services multi-utilisateurs ou robot, nécessite de générer la clé secret et configuration intrinsèque
Possibilité de mettre facultatif l’authentification double facteurs
Modification rapide du jeton d’authentification

Certaines solutions tierces ne prennent pas en charge la MFA. Ce qui peux poser un problème et ce malgré la précision du NULLOK.

Dans mon cas, quatre solutions sont envisageables :

Présenter à l’éditeur de la solution le cas et demander si une évolution est possible. Si oui, désactiver temporairement la MFA si le risque est maitrisé et contenu
Etudier le remplacement de la solution Tierce et garder le niveau de sécurité en place. Attention toutefois car cela aura des couts financiers, humains
Désactiver la MFA si le risque est maitrisé et si rien ne peut être réalisé
Déployer un nouveau serveur, Appliance dédié au client ou application concernés sans fonctionnalité de MFA

Le mot de la fin :

Je vais un tour du côté de chez SWAN. Je MFA ma culotte de chasteté, j’ai perdu le codex et envie de pisser.
Erwan GUILLEMARD

Activer la génération des tokens basés sur le temps. (Y)
Scanner et enregistrer le QRcode ainsi que les 5 codes de secours lorsque vous aurez saisie le code généré par l’application. La perte de ces informations ne vous permettra plus à l’avenir de vous authentifier. Vous pouvez également préciser l’url comme source TOIP en copiant l’URL fournit en amont du QRCode. Mettez à jour le fichier google_authenticator (Y)

Prémunissez vous des attaques man-in-the-middle en saisissant (Y) Ne permettez pas la durée de vie d’un token au-delà de 40 minutes une fois les 30 secondes écoulées (N)
Activer la fréquence de limitation dans le cas d’échec d’authentification au-delà de 3 tentatives (Y)

LINUX – MFA