Admin/Modo : J'ai placé cet article ici car c'est sans doute la section la plus visitée par les débutants, mais également car je n'ai pas vu de section concernant la sécurité de nos RPI.
Je me permets de faire une piqûre de rappel à tous ceux qui souhaitent accéder à leur RPI depuis l’extérieur de leur réseau.
Je ne parlerai pas ici des différentes possibilités pour y accéder depuis le web.
Je me concentrerai principalement sur la sécurité du SSH et les bonnes pratiques s'y référant.
Avec cet article, mon but :
n'est pas de vous effrayer avec mes propos
n'est pas de partir à la chasse aux sorcières
n'est pas de chercher à stigmatiser les systèmes trop peu voir non sécurisé
n'est pas de polémiquer sur la sécurité informatique.
est de vous conscientiser sur l'importance de la sécurité informatique
est de vous apporter des "best pratice" pour diminuer le risque d'intrusion sur votre RPI via SSH
Un utilisateur avancé aura sans doute déjà remarqué que, si vous ouvrez votre port 22 (SSH) vers l'extérieur, il ne faut pas très longtemps pour que ce dernier soit attaqué (brute force, dictionnaire et autres Script-kiddies).
Vous pouvez facilement l'observer dans le fichier de log /var/log/auth.log de votre Debian ou Raspbian.
Voici certaines des bonnes pratiques actuelles (mais pas obligatoire) pour sécuriser votre SSH :
- Interdire à root de se connecter en SSH. Dans le fichier /etc/ssh/sshd_config, mettre l'option "PermitRootLogin yes" à "no".
Le premier utilisateur testé durant une attaque en SSH, c'est root, viens ensuite les utilisateurs admin, a, test, ... (sur base de mes propres statistiques).Code : Tout sélectionner
# Authentication: LoginGraceTime 120 PermitRootLogin no StrictModes yes
Lui interdire l'accès en SSH réduit considérablement le risque d'intrusion.
Cette option n'interdit pas de se connecter en root avec son password en local.
Si vous, ou vos applications, avez besoin d’accéder à votre RPI en root en SSH, utilisez des clés SSH public/privé pour root en mettant dans le fichier /etc/ssh/sshd_config, l'option "PermitRootLogin yes" à "without-password".
Cette option interdit à root de se connecter en SSH avec un mot de passe, mais autorise l'accès grâce aux "clés SSH" (voir le point 2).Code : Tout sélectionner
# Authentication: LoginGraceTime 120 PermitRootLogin without-password StrictModes yes
- Essayer, dans la mesure du possible, d'utiliser des clés public/privée pour vous connecter en SSH avec tous vos utilisateurs.
L'utilisation de clés à plusieurs effets positifs :- plus besoin de taper son password
- possibilité d'automatiser des actions tel que des backup
par exemple : rsync - exécution de commande à distance:
par exemple la mise à jour : "aptitude update && aptitude upgrade"
- oubli du son password
Nous voilà obligé de forcer notre propre système. - possibilité de se tromper de serveur/RPI
Très ennuyeux si on arrête un serveur en production en pleine journée. - perte des clés SSH
Suite à un crash disque par exemple.
Nous voilà obligez de nous remémorer notre password, sinon retour au point A. - vol des clés SSH
Le plus ennuyeux, car presque invisible :
nous somme toujours capable de nous connecter sur notre serveur SSH, mais quelqu'un d'autre aussi.
Heureusement, il y a des solutions pour palier à ce risque.
Voici un tuto très succinct pour créer vos clé SSH.
Voici un tuto plus complet pour les utilisateurs confirmés.
Pour transférer facilement vos clé sur votre serveur/RPI, il existe la commande ssh-copy-id - Installer fail2ban.
Ce soft banni une adresse IP pendant 10 minutes après 3 tentatives erronées.
Ce soft est utilisable sur le SSH par défaut mais aussi sur l'HTTP (et un htpwd) en configurant le fail2ban.
Ce soft réduit considérablement le risque d'intrusion en SSH, mais le ramène pas à ZÉRO.
Pour vous donner un exemple, avec fail2ban installé sur un de mes serveurs, j'ai eu un total de 12'442 tentatives (+/- 34 tentatives par jour) en SSH en 2013.
Mais sans se soft, vous pouvez avoir jusqu'à 600 tentatives par jour (sur base de mes propres statistiques), voir plus, ce qui ferai un total de 219'000 tentatives en 1 an.
Il est peu gourmand et très efficace, il est pré-configuré pour SSH et fonctionne avec iptables (site en anglais). - Changer le password de l'utilisateur pi de votre RPI.
Ce dernier étant déjà inclus dans les différents dictionnaires et script-kiddies disponibles sur le web, le risque que votre RPI/réseau soit "compromis" est de proche 100%. - Utiliser un password complexe, avec des lettres minuscules, majuscules, des chiffres, des caractères spéciaux et de longueur suffisante.
Inventons et analysons un nouveau password pour l'occasion avec uniquement des minuscules (26 possibilités), majuscules (26 possibilités), des chiffres (10 possibilités) et un longueur de 10 caractères : r45Pb3Ryp1.
Ce dernier aura une probabilité d'être découvert en brute force de 1 sur ((26*26*10)^10) = 1,99281489×10³⁸ (pour les matheux). Autrement dis : Bonne chance les coco.
Ce nouveau password n'étant probablement pas dans un dictionnaire disponible sur le web, le risque d'une intrusion sur votre RPI/réseaux est faible.
Analysons maintenant le password par défaut de l'utilisateur Pi : raspberry
Ce password par défaut aura une probabilité d'être découvert en brute force de 1 sur ((26)^9) = 5,429503679×10¹² (pour les matheux). Autrement dis : Bonne chance les coco.
Cependant, n'oublions pas que ce password est déjà inclus dans les différents dictionnaires et script-kiddies disponibles sur le web, ce qui augmente le risque que votre RPI/réseau soit "compromis". - Changer le port du SSH.
Il est possible de changer le port du serveur SSH du RPI en modifiant dans le fichier /etc/ssh/sshd_config, l’option "Port 22" avec un port compris entre 1024 et 65535.
Ou en configurant son modem/routeur/firewall à rediriger un port externe compris entre 1024 et 65535 sur le port 22 du serveur/RPI.
Cependant, il faut savoir que d'autres ports se rapprochant du port 22, tel que le 2022 ou encore le 2222, sont aussi attaqués en SSH, car ils sont fortement utilisé sur le net.
Pour vous donner un exemple, dans ma configuration : j'ai interdis l'accès à root sauf avec une clé SSH, j'utilise un password complexe (c'est le minimum), mais mes clés SSH personnelles n'ont pas de password (sauf au travail) et je n'ai pas changé le port par défaut de SSH, celui-ci est accessible depuis l'extérieur de mon réseau sur le port 22.
Il est, par contre, recommandé d'en appliquer un maximum sur un serveur/RPI hébergeant des données confidentielles/personnelles ou sur un serveur/RPI considéré comme critique/vitale.
Voilà, j'espère que cet article vous aura aidé à sécuriser votre serveur SSH.
Si vous avez des questions, n'hésitez pas.
Je vous souhaites à toutes et à tous une bonne journée.