Raspberry PI – sécuriser ssh

    Voilà, le Raspbian vient d’être installé et maintenant, il nous est possible de communiquer avec notre petit ordinateur via la connexion ssh. Si vous voulez gérer votre propre serveur, vous devez absolument utiliser ce service pour y accéder à distance. Il est indispensable car en plus d’un accès via la ligne de commande, il permet également de déposer vos fichiers, ce qui évite l’installation d’un serveur ftp supplémentaire. Parce que en règle générale, les utilisateurs accèdent au système distant en utilisant leur login et mot de passe. Cela signifie aussi qu’un mauvais pirate peut essayer d’avoir un compte sur ce système dans le but d’accéder à vos fichiers ou pour l’utiliser comme une passerelle pour attaquer d’autres systèmes informatisé. Pour le faire, il essayera plein de mots de passes différents pour un même login. En général, ce type d’attaques est entièrement automatisé. Il est effectué à l’aide d’un dictionnaire de mots de passe, utilisés le plus fréquemment. Nous l’appelons une attaque par la force brute.

Supprimer l’utilisateur par défaut

Nous allons créer un nouvel utilisateur ramses, qui remplacera pi (utilisateur par défaut du système Raspbian).

  • Repérer les groupes de l’utilisateur pi
pi@raspberry:~ $ sudo groups pi
pi : pi adm dialout sudo audio video plugdev users netdev input
pi@raspberry:~ $
  • Ajouter le nouveau utilisateur ramses qui intégrera les mêmes groupes
pi@raspberry:~ $ sudo useradd -m -G adm,dialout,sudo,audio,video,plugdev,users,netdev,input ramses
pi@raspberry:~ $ sudo passwd ramses
Entrez le nouveau mot de passe UNIX : 
Retapez le nouveau mot de passe UNIX : 
passwd: password updated successfully
pi@raspberry:~ $ sudo reboot

Choisissez le mot de passe fort et complexe

 

  • Se reconnecter avec votre nouveau utilisateur
user@kali-master:~$ ssh ramses@192.168.0.25
ramses@raspberry's password: 
Linux svr02 4.14.98-v7+ #1200 SMP Tue Feb 12 20:27:48 GMT 2019 armv7l
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.
ramses@raspberry:~ $  
  • Supprimer utilisateur pi
ramses@raspberry:~ $ sudo deluser --remove-all-files pi
Nous espérons que vous avez reçu de votre administrateur système local les consignes traditionnelles. 
Généralement, elles se concentrent sur ces trois éléments :
#1) Respectez la vie privée des autres.
#2) Réfléchissez avant d'utiliser le clavier.
#3) De grands pouvoirs confèrent de grandes responsabilités.
[sudo] Mot de passe de ramses : 

 

Vous l’avez sans doute remarqué que pour lancer une commande nécessitante les droits root, vous êtes obligé de saisir une seconde fois le mot de passe de l’utilisateur. Cependant, avec l’utilisateur pi, en saisissant sudo -i vous basculiez directement en root. Cette possibilité est due notamment au fichier /etc/sudoers.d/010_pi-nopasswd

Donc si vous souhaitez revenir comme avant, parce que c’était plus conviviale pour vous

ramses@raspberry:~ $ sudo-i
[sudo] Mot de passe de ramses :
root@raspberry:~# cat > /etc/sudoers.d/010_ramses-nopasswd << eof
> ramses ALL=(ALL) NOPASSWD: ALL
> eof
root@raspberry:~# rm -r /etc/sudoers.d/010_pi-nopasswd
root@raspberry:~# reboot

Après redémarrage, cette modification sera prise en compte

La suppression du compte pi installé par défaut, est la première étape pour avoir un peu plus de sécurité sur son serveur Raspberry PI. Suivant cette logique, nous allons engager d’autres actions afin sécuriser le service ssh

Configurer les clefs shell

      Face à la faiblesse de l’authentification par mot de passe, l’authentification par clé se révèle être plus efficace. La clé permet de garantir à un système qu’un utilisateur est bien celui qu’il prétend être.

L’authentification par clefs fonctionne avec trois composants :

  • Une clé publique – sera exportée sur chaque hôte sur lequel on souhaite pouvoir se connecter
  • Une clé privée – permet de prouver son identité aux serveurs
  • Une passphrase – permet de sécuriser la clé privée

La sécurité est vraiment accrue car la passphrase seule ne sert à rien sans la clé privée, et vice-versa.

  • La cryptographie asymétrique

Le serveur ssh utilise la cryptographie asymétrique. En cryptographie asymétrique, chaque personne dispose d’un jeux de clé composé d’une clé publique et une clé privée. La clé publique peut être librement publiée, mais la clé privée doit impérativement rester secrète. La connaissance de la clé publique ne permet en aucun cas d’en déduire la clé privée.

Son principe est simple :

Alice veut envoyer un message confidentiel à Bob. Elle crypte alors le message avec la clé publique de Bob et lui l’envoie à travers du réseau, qui n’est pas forcément sécurisé. Seulement Bob pourra décrypter le message en utilisant sa clé privée.

  • La cryptographie symétrique

Le serveur ssh utilise également la cryptographie symétrique.

Son principe est simple :

Alice veut envoyer un message confidentiel à Bob. Pour cela, Alice et Bob doivent être en possession d’une même clé secrète. Alice crypte le message avec la clé secrète et l’envoie à Bob à travers du réseau, qui n’est pas forcément sécurisé. Bob décrypte le message grâce à la clé secrète commune. Toute autre personne qui possède la clé secrète peut décrypter le message.

La cryptographie symétrique nécessite beaucoup moins de ressources que la cryptographie asymétrique. Le grand problème est l’échange de la clé secrète. Dans le protocole ssl, la cryptographie asymétrique est utilisée au début de la communication. Cela permet une échange de la clé secrète de manière sécurisée. La suite de la communication est sécurisée avec la cryptographie symétrique et elle utilise la clé secrète échangée.

  • Établissement d’une connexion SSH

Le serveur dispose d’une paire de clés RSA stocké dans le répertoire /etc/ssh/ Ces clés sont généré pendant son installation. Le fichier ssh_host_rsa_key contient la clé privée et le fichier ssh_host_rsa_key.pub contient la clé publique.

Le schéma de fonctionnement est le suivant:

  • Le serveur envoie sa clé publique au client.
  • Le client génère une clé secrète et l’envoie au serveur. L’échange est cryptée avec la clé publique du serveur (cryptographique asymétrique). En utilisant sa clé privée, le serveur décrypte la clé secrète du client, ce qui confirme son authenticité.
  • Pour le prouver au client, il crypte un message standard avec la clé secrète et l’envoie au client. Si le client retrouve le message standard en utilisant la clé secrète, il a la preuve que le serveur est bien le vrai serveur.
  • Après échange de la clé sécrète, le client et le serveur établissent alors un canal sécurisé grâce à la clé secrète commune (cryptographie symétrique).
  • Une fois que le canal sécurisé établi, le client pourra envoyer son login et le mot de passe pour vérification. La canal sécurisé reste en place jusqu’à ce que l’utilisateur ne quitte pas sa connexion.

La seule contrainte est de s’assurer que la clé publique présentée par le serveur est bien sa clé publique. Dans le cas contraire, le client risque de se connecter à un faux serveur qui aurait usurpé l’adresse IP du vrai. Une bonne méthode est la connaissance de fingerprint de la clé publique du serveur, qui a été récupéré lors de votre première connexion. C’est une chaîne de 32 caractères hexadécimaux unique pour chaque clé et stocké dans votre répertoire utilisateur ~./ssh/known_hosts.

  • Génération des clefs utilisateurs

Voyons tout d’abord comment générer une paire de clés et comment exporter la clé publique sur le serveur en utilisant la ligne de commande. Pour cela, nous allons utiliser:

user@kali-master:~$ cd $HOME/.ssh
user@kali-master:~/.ssh$ ssh-keygen -b 4096
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa): MonServeur
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in MonServeur.
Your public key has been saved in MonServeur.pub.
The key fingerprint is:
SHA256:5DpsgENmLOtIB3A0l9oFEopVhqJAN3+9OMbJcwBTeow user@kali-master
The key's randomart image is:
+---[RSA 4096]----+
|ooB*==.. |
|==o=+ B . |
|*o=o E =.. |
|.*o.. =o+ . |
|..o.. OSo |
|+ .. o..+ |
|.. = |
| . . |
| |
+----[SHA256]-----+
user@kali-master:~/.ssh$ cat MonServeur.pub >> $HOME/.ssh/authorized_keys
user@kali-master:~/.ssh$ ssh-copy-id -i ~/.ssh/MonServeur.pub ramses@192.168.0.25
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/horus/.ssh/MonServeur.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s)
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed 
ramses@raspberry's password: 
Number of key(s) added: 1
Now try logging into the machine, with:   "ssh 'ramses@raspberry'"
and check to make sure that only the key(s) you wanted were added.
userkali-master:~/.ssh$

  • Configuration du serveur

La configuration du serveur ssh est fait par l’intermédiaire du fichier sshd_config situé dans le répertoire /etc/ssh/

Voici quelques modifications que vous devez y apporter

  • Désactivation de mot de passe

Retrouvez et dé-commentez la ligne suivante et attribuez lui la valeur no

#PasswordAuthentication no -> PasswordAuthentication no

  • Écoute une interface réseau spécifique

Si vous disposez de plusieurs interfaces réseaux sur votre serveur, mais vous ne voulez qu’on puisse ce connecter en ssh que d’une seule interface.
Retrouvez et dé-commentez la ligne suivante en lui  ajoutant l’IP de la seul interface que le serveur ssh doit écouter

#ListenAddress -> ListenAddress 192.168.0.254

  • Liste des comptes utilisateurs

Il est possible de mettre en place une liste des comptes utilisateurs qui seront autorisés à se connecter. Pour cela, retrouvez et dé-commentez la ligne suivante en les utilisateurs autorisé les un après les autres séparé par un espace.

#AllowUsers -> AllowUsers ramses toto bidul

 

Pour activer les modifications, le redémarrage de votre serveur est nécessaire :

ramses@raspberry:~$ sudo /etc/init.d/ssh restart
[ ok ] Restarting ssh (via systemctl): ssh.service.
ramses@raspberry:~$ 

 

L’authentification par clefs est la seconde étape pour améliorer la sécurité de votre serveur Raspberry PI. Suivant cette logique, nous allons engager d’autres actions afin améliorer d’avantage la sécurité du service ssh

2FA avec Google authenticator

      Google authenticator permet d’ajouter une protection supplémentaire. C’est un code généré par une application spécifique, qui était installée sur votre smartphone. Cela signifie que si le mauvais pirate avait réussi vous voler votre login, votre passphrase et vos clefs, il ne pourra pas se connecter à votre place. Pour cela, il sera obligé vous voler aussi votre smartphone et connaître son code de déverrouillage. Cette méthode d’authentification vient en complément et améliore considérablement la sécurité de votre serveur.

Application disponible pour Android et iOS

Google Play

App Store

  • Installer des paquets nécessaires

ramses@raspberry:~ $ sudo apt-get install libpam-google-authenticator
Lecture des listes de paquets… Fait
Construction de l’arbre des dépendances
Lecture des informations d’état… Fait
The following additional packages will be installed:
libqrencode3
Les NOUVEAUX paquets suivants seront installés :
libpam-google-authenticator libqrencode3
0 mis à jour, 2 nouvellement installés, 0 à enlever et 0 non mis à jour.
Il est nécessaire de prendre 58,6 ko dans les archives.
Après cette opération, 174 ko d’espace disque supplémentaires seront utilisés.
Souhaitez-vous continuer ? [O/n] O
Réception de:1 http://raspbian.42.fr/raspbian stretch/main armhf libqrencode3 armhf 3.4.4-1 [29,4 kB]
Réception de:2 http://raspbian.42.fr/raspbian stretch/main armhf libpam-google-authenticator armhf 20160607-2 [29,2 kB]
58,6 ko réceptionnés en 0s (147 ko/s)
Sélection du paquet libqrencode3:armhf précédemment désélectionné.
(Lecture de la base de données… 34707 fichiers et répertoires déjà installés.)
Préparation du dépaquetage de …/libqrencode3_3.4.4-1_armhf.deb …
Dépaquetage de libqrencode3:armhf (3.4.4-1) …
Sélection du paquet libpam-google-authenticator précédemment désélectionné.
Préparation du dépaquetage de …/libpam-google-authenticator_20160607-2_armhf.deb …
Dépaquetage de libpam-google-authenticator (20160607-2) …
Paramétrage de libqrencode3:armhf (3.4.4-1) …
Traitement des actions différées (« triggers ») pour libc-bin (2.24-11+deb9u4) …
Traitement des actions différées (« triggers ») pour man-db (2.7.6.1-2) …
Paramétrage de libpam-google-authenticator (20160607-2) …
ramses@raspberry:~ $

  • Lancer google-authenticator et scanner le code QR avec votre smartphone
ramses@raspberry:~ $ 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/ramses@raspberry
%3Fsecret%3DJKKU3PHWYXKSVFM4IITMQA74C4%26issuer%3Dsvr0



Your new secret key is: JKKU3PHWYXKSVFM4IITMQA74C4
Your verification code is 992967
Your emergency scratch codes are:
84258890
46757103
99152242
34293862
30023330
Do you want me to update your "/home/ramses/.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

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. 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 +-1min (window size of 3) to about +-4min (window size of
17 acceptable tokens).
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) 
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
ramses@raspberry:~ $ 

Une série de codes d’urgences a été généré et vous devez absolument les conserver dans un endroit sûr. Ce sont ces codes qui vous permettent de vous connecter à votre serveur en cas de problème avec votre smartphone.

 

  • Finaliser la configuration

 

  • Modifier fichier /etc/pam.d/sshd

ramses@raspberry:~ $ sudo nano /etc/pam.d/sshd

Ajouter  la ligne:

auth required pam_google_authenticator.so

 

  • Modifier /etc/ssh/sshd_config
ramses@raspberry:~ $ sudo nano /etc/ssh/sshd_config

Retrouvez et dé-commentez la ligne suivante et attribuez lui la valeur Yes

#ChallengeResponseAuthentication no -> ChallengeResponseAuthentication yes

 

  • Redémarrer le serveur

ramses@raspberry:~$ sudo /etc/init.d/ssh restart
[ ok ] Restarting ssh (via systemctl): ssh.service.
ramses@raspberry:~$

 

L’authentification 2FA est la troisième étape qui améliore considérablement la sécurité de votre serveur Raspberry PI.