Table de Matieres
I. Présentation de l’OTP/Google Authenticator
La sécurité des accès à privilèges doit faire l’objet de toute l’attention des administrateurs systèmes et des RSSI. Aujourd’hui, les faiblesses du couple login/password en terme de sécurité ne sont plus à prouver et il est commun de voir apparaître des solutions d’authentification multi-facteurs. Pour rappel, une authentification peut se baser sur plusieurs facteurs :
- Ce que je sais : un mot de passe
- Ce que je sais faire : une signature
- Ce que je possède : un smartphone, un Token USB
- Ce que je suis : empreintes digitales
L’utilisation de plusieurs de ces facteurs pour un même accès est alors appelé authentification forte. La solution la plus accessible pour la mise en place de l’authentification forte sur un accès est l’OTP (One Time Password). Le principe de l’utilisation de l’OTP est donc d’être en possession d’un appareil/objet qui va générer régulièrement un mot de passe. Ce mot de passe ne sera utilisable qu’une fois et valable pour un délai très court. Un pirate qui entrera en possession de mon login et de mon mot de passe devra alors également se saisir de mon générateur d’OTP. Communément, les générateurs d’OTP sont des petites clés (type clés USB) ou des applications sur smartphone.
Dans un tel contexte, l’authentification se base donc sur :
- Ce que je sais : mon mot de passe
- Ce que je possède : mon générateur d’OTP
Dans ce tutoriel, nous allons étudier la configuration permettant de mettre en place une authentification forte sur l’accès SSH. Les accès SSH sont les plus convoités des pirates car ils permettent de prendre possession d’un serveur très rapidement, également, ils sont majoritairement utilisés par les administrateurs.
La solution utilisée sera dans notre cas Google Authenticator, une application gratuite que l’on peut trouver sur Android et iOS. La configuration nécessite l’installation d’une librairie permettant de prendre en charge ce nouveau mode d’authentification, la modification de la configuration SSH, puis l’enrôlement de l’application Google Authenticator pour que l’application de votre smartphone génère des OTP propre à votre compte.
Ce tutoriel est basé sur les éléments suivants :
- un serveur Debian 8.3
- un service OpenSSH 6.7
- l’application Google Authenticator v4.44
II. Configuration côté serveur
Nous allons naturellement commencer par procéder à l’installation côté serveur.
A. Installation de la librairie
La première étape est donc de télécharger et compiler la librairie « pam_google_authenticator » pour PAM.
PAM ou « Pluggable Authentication Modules » est le mécanisme qui va gérer l’authentification sous Linux. Il possède l’avantage d’être hautement configurable et modulable, ce qui nous permet de modifier le scénario d’authentification afin de faire entrer en jeu le système OTP 🙂
Celle-ci sera notamment utilisée par le système d’authentification de notre serveur lors du traitement de la demande/réponse de l’OTP, on commence par installer les paquets suivants :
apt-get install build-essential make libpam0g-dev libpam0g
La librairie libpam0g est ici importante, elle permet à l’administrateur du système de choisir la façon dont les applications (dont OpenSSH Server) va authentifier ses utilisateurs. Ensuite, nous téléchargeons la librairie en elle-même :
cd /tmp wget https://google-authenticator.googlecode.com/files/libpam-google-authenticator-1.0-source.tar.bz2 -O googleauth.tar.bz2 tar -xf googleauth.tar.bz2 && rm googleauth.tar.bz2 cd libpam-google-authenticator-1.0/
Nous allons ensuite la compiler avec les commandes habituelles :
make make install
Cette dernière commande nous retourne l’affichage suivant :
cp pam_google_authenticator.so /lib/x86_64-linux-gnu/security cp google-authenticator /usr/local/bin
Nous avons maintenant à notre disposition la librairie PAM nommée pam_google_authenticator, celle-ci sera utilisée par PAM et le serveur SSH lors de l’authentification des utilisateurs . Également, nous avons une commande nommée « google-authenticator« , cette commande sera utilisée par les utilisateurs afin d’enrôler leur application Google Authenticator, nous verrons cela dans le prochain chapitre 🙂
B. Modification de la configuration SSH
A présent, nous avons la possibilité d’intégrer l’utilisation de l’OTP dans le mécanisme d’authentification SSH, rien de plus simple dans notre cas, il suffit de modifier un paramètre dans le fichier de configuration d’OpenSSH server : /etc/ssh/sshd_config
Nous allons y trouver le paramètre suivant :
ChallengeResponseAuthentication no
et passer le « no » à « yes » :
ChallengeResponseAuthentication yes
Pour information, ce paramètre permet d’accepter l’authentification via un échange challenge-response. Il nous faut ensuite modifier le scénario d’authentification de l’application SSH pour y intégrer la phase OTP au niveau PAM. Pour cela, nous nous rendons dans le fichier /etc/pam.d/ssh pour y ajouter la ligne suivante à la ligne 44 :
auth required pam_google_authenticator.so
Voici à quoi ressemblera la structure finale du fichier dans la zone modifiée :
(...) # Print the status of the user's mailbox upon successful login. session optional pam_mail.so standard noenv # (1) # Set up user limits from /etc/security/limits.conf. session required pam_limits.so # Read environment variables from /etc/environment and # /etc/security/pam_env.conf. auth required pam_google_authenticator.so session required pam_env.so # (1) # In Debian 4.0 (etch), locale-related environment variables were moved to # /etc/default/locale, so read that as well. session required pam_env.so user_readenv=1 envfile=/etc/default/locale (...)
Pour finir, et prendre en compte nos dernières modifications, il faut redémarrer le service SSH :
service ssh restart
L’intégration de l’OTP est maintenant terminée pour ce qui concerne les modifications côte serveur.
III. Configuration côté client
Nous allons maintenant passer à la « configuration » côté client. Il faut en effet que le client soit synchronisé au niveau de son application Google-authenticator sur smartphone. La première étape est donc télécharger sur votre smartphone l’application Google Authenticator :
Voici l’interface de Google Authenticator, les utilisateurs peuvent y gérer leurs comptes :
La seconde étape consiste à générer une clé de sécurité qui va nous permettre de raccorder notre application à notre compte. Nous allons donc nous connecter en SSH avec l’utilisateur qui doit utiliser l’authentification forte, et exécuter la commande suivante :
google-authenticator
Différente option son alors paramétrables :
- A la question « Do you want authentication tokens to be time-based (y/n) « , saisir « y« , cela permet donc de générer des tokens basé sur l’heure et la date actuelle.
- A la question « Do you want me to update your « /home/adminadmin/.google_authenticator » file (y/n)« , saisir « y« , le fichier ~./google_authenticator permet de stocker les informations concernant l’enrôlement de l’application smartphone. Il est stocké dans le dossier /home de l’utilisateur actuel. C’est pour cette raison qu’il est important d’effectuer cette commande avec l’utilisateur actuel sur le serveur cible.
- A la question « Do you want to disallow multiple uses of the same authenticationtoken?« , saisir « y« , cela permet d’éviter les possibilités de rejeu d’un token déjà utilisé.
- A la prochaine question, répondre « n« , cela fixe le délai de validité d’un token à 30 secondes, ce qui est généralement suffisant. ce paramètre sera modifiable ultérieurement si besoin, comme les autres d’ailleurs
- A la dernière question, répondre « y« , cette dernière question permet de limiter le nombre de token tenté afin d’éviter le brute force.
Voici la trame complète :
adminadmin@debian:~$ google-authenticator Do you want authentication tokens to be time-based (y/n) y https://www.google.com/chart?chs=200x200&chld=M|0&cht=qr&chl=otpauth://totp/adminadmin@debian%3Fsecret%3DG7WH6ZQJATNDMX4C Your new secret key is: G7WH6ZQJATNDMX4C Your verification code is 551013 Your emergency scratch codes are: 60955400 59847646 47168104 48025356 44020894 Do you want me to update your "/home/adminadmin/.google_authenticator" file (y/n) y Do you want to disallow multiple uses of the same authentication token? This restricts you to one login about every 30s, but it increases your chances to notice or even prevent man-in-the-middle attacks (y/n) y By default, tokens are good for 30 seconds and in order to compensate for possible time-skew between the client and the server, we allow an extra token before and after the current time. If you experience problems with poor time synchronization, you can increase the window from its default size of 1:30min to about 4min. Do you want to do so (y/n) n If the computer that you are logging into isn't hardened against brute-force login attempts, you can enable rate-limiting for the authentication module. By default, this limits attackers to no more than 3 login attempts every 30s. Do you want to enable rate-limiting (y/n) y
Vous aurez remarqué qu’une clé de sécurité a été générée à la seconde étape (question), dans cette trame exposée en exemple, il s’agit de « G7WH6ZQJATNDMX4C« .
Cette clé est à fournir dans l’application Google Authenticator après avoir été dans « Saisir la clé fournie« , nous pourrons alors donner un nom à notre nouvelle clé et la saisir dans le champ « Saisissez votre clé » :
Une fois cette opération effectuée, vous pourrez voir l’OTP généré de façon régulière. Nous pourrons alors effectuer notre première connexion SSH en utilisant notre OTP :
ssh utilisateur@IPserveur
Voici l’affichage que l’on pourra avoir :
mickael (~) 20:51 > ssh (email protected) Password: Verification code: The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. You have mail. Last login: Wed Jan 27 20:29:25 2016 from localhost adminadmin@debian:~$
Nous voyons donc bien que le mot de passe est demandé, puis s’il est validé, le « Verification Code« , qui est donc l’OTP généré dans l’application Google Authenticator.
Cette procédure vous permettra donc d’améliorer la sécurité de votre accès SSH, en empêchant notamment les brutes force. En effet, même si l’attaquant trouve le mot de passe de votre compte utilisateur, il devra en plus être en possession de l’OTP, qui a une durée de vie de 30 secondes seulement.
Hébergez votre site à partir de 2$ sur 👉👉👉 https://www.tnctech.ca