[Sécurité] Sécuriser son serveur SSH

Violence

Le tutoriel d’installation est disponible sur le wiki en suivant le lien ci-dessous :

https://wiki.planete-warez.net/informatique/sécurité/secure-ssh

Sommaire

I. Présentation

II. Sécurisation générale de SSH

A. Modifier le port et l’interface réseau d’écoute par défaut
B. Configurer le timeout des sessions SSH
C. Empêcher la connexion de l’utilisateur root en SSH

III. Sécuriser l’authentification par mot de passe classique

A. Autoriser seulement la connexion pour un ou plusieurs utilisateurs.

IV. Authentification par clés publique/privée

A. Désactivez l’authentification par mot de passe classique

V. Pour aller plus loin

I. Présentation

– Dans ce tutoriel, nous allons voir comment sécuriser le service SSH sous Linux, en respectant quelques best practices en matière de configuration d’un serveur SSH.

– Le protocole SSH est recommandé pour la connexion à distance, la réalisation de sauvegardes, le transfert de fichiers à distance via scp ou sftp, et bien plus encore. SSH est parfait pour préserver la confidentialité et l’intégrité des données échangées entre deux machines situées sur des réseaux différents, ou sur le même réseau.

– Son principal avantage est l’authentification du serveur, grâce à l’utilisation de la cryptographie à clé publique pour l’authentification. (aussi appelée SSH password-less). Sous Linux (et Windows), l’implémentation de ce protocole se fait par le biais du packet OpenSSH.

– Depuis quelques années, au grès des mises à jour, OpenSSH a vu sa sécurité durcie, notamment en ce qui concerne les messages d’erreurs (trop verbeux) au départ. Ce guide ne sera pas très long étant donné que les développeurs ont fait un gros effort afin d’éviter que la configuration d’OpenSSH ne soit trop permissive par défaut.

Environnement :

Client SSH : Kali Linux (2021.3) - 192.168.175.128
Serveur SSH : Ubuntu 20.04.1 LTS - 192.168.175.129
Deux utilisateurs : tintin, haddock

–> Toutes les commandes ci-dessous seront exécutées par l’intermédiaire de l’utilisateur root.

– Avant de commencer, installez SSH sur votre serveur :

sudo apt install openssh-server
# apt utilise aussi l'alias ssh, pour identifier le paquet openssh-server

II. Sécurisation générale de SSH

– Quelle que soit la méthode de connexion au serveur SSH, il y a certaines règles communes à respecter afin de brouiller les pistes pour un attaquant :

Modifier le port et l’interface réseau d’écoute par défaut
Fixer un Idle timeout pour ne pas avoir de sessions SSH qui restent actives
Empêcher la connexion de l’utilisateur root (sur les distributions Linux récentes, cette fonctionnalité est désactivée par défaut)
etc.

– Pour cela, nous allons modifier le fichier /etc/ssh/sshd_config de notre serveur SSH. Editez ce fichier avec votre éditeur préféré :

sudo nano /etc/ssh/sshd_config

A. Modifier le port et l’interface réseau d’écoute par défaut

– Par défaut, le port d’écoute SSH est 22, changez le afin de brouiller les pistes. Pour cela, modifiez le paramètre Port du fichier de configuration :

Port 2021

– L’interface d’écoute du protocole SSH est par défaut “Toutes les interfaces” : 0.0.0.0/0.

Changez ce paramètre, afin que votre serveur SSH accepte seulement les connexions sur votre interface principale. Si vous n’avez pas plusieurs interfaces réseau (j’entends par la carte réseau) et adresses IP sur votre serveur, vous pouvez vous passer de cette modification.

– Pour que SSH écoute seulement sur l’adresse IP “192.168.175.129”, voici la configuration :

ListenAddress 192.168.175.129

– Puis, redémarrez le service :

systemctl restart ssh

B. Configurer le timeout des sessions SSH

– Pour cette troisième modification, nous allons définir un temps maximal d’inactivité pour une session SSH, afin d’éviter que certaines connexions SSH restent actives indéfiniment.

– Dans ce cas précis, si le service SSH ne détecte aucune activité sur le flux de connexion (en bref, si aucune commande n’est saisie pendant un laps de temps), alors il terminera automatiquement la connexion.

–Si vous souhaitez que le client SSH se ferme (timeout) automatiquement après 10 minutes (600 secondes), modifiez le fichier sshd_config et définissez les deux paramètres suivants comme indiqué ci-dessous.

ClientAliveInterval : ceci indique le délai d’attente en secondes. Après x secondes, le serveur SSH enverra un message au client demandant une réponse.
ClientAliveCountMax : ceci indique le nombre total de messages de vérification envoyés par le serveur SSH sans obtenir de réponse du client SSH.

– Nous en avons fini avec cette partie. Quelle que soit votre configuration, respectez ces règles. Pour valider ces changements, redémarrez le service SSH :

systemctl restart ssh

– Si vous avez modifié le port SSH, il faudra vous reconnecter en utilisant le nouveau port.

C. Empêcher la connexion de l’utilisateur root en SSH

– Même si depuis bien des années maintenant, la connexion de l’utilisateur root est désactivée par défaut dans la configuration SSH, il se peut que sur certaines vieilles bécanes, le processus d’authentification du super-utilisateur soit actif. Pour cela, recherchez la ligne suivante, et affectez lui la valeur No :

PermitRootLogin No

– Pour un site sur lequel on travaille, c’est un peu pénible de ne pas pouvoir se connecter en root, on pourrait être tenté d’activer l’accès root mais je le déconseille.

A savoir que si la connexion root vous est nécessaire, elle demeure toutefois une faille de sécurité potentielle.

III. Sécuriser l’authentification par mot de passe classique

– Depuis que l’authentification par clé publique/privée existe, cette méthode est de moins en moins utilisée et déconseillée (car trop sensible aux attaques par brute force si le service SSH est mal configuré).

– Toutefois, dans certains cas pour des serveurs n’étant pas hautement stratégiques, et non atteignables depuis internet, nous pouvons garder la méthode d’authentification classique. Dans cette partie, nous allons voir comment sécuriser cette méthode d’authentification.

A. Autoriser seulement la connexion pour un ou plusieurs utilisateurs.

– Dans mon cas, j’ai créé deux utilisateurs en amont :

tintin
haddock

sudo nano /etc/ssh/sshd_config

– Je vais autoriser seulement tintin à se connecter en SSH sur mon serveur.
Ajoutez cette ligne :

AllowUsers tintin

–Sauvegardez les changements, et redémarrer votre service SSH:

systemctl restart ssh

– Tentez une connexion SSH depuis votre machine cliente en précisant l’utilisateur haddock :

–> Comme l’utilisateur haddock n’est pas présent dans la liste, il se verra automatiquement refuser la connexion.

– Vous préférez spécifier un groupe pour l’autorisation de connexion en SSH ? Ajoutez vos utilisateurs à un groupe, et spécifiez celui-ci dans la configuration de SSH.

Par exemple :

AllowGroups MonGroupeSSH

IV. Authentification par clés publique/privée

– Il existe un moyen radical de sécuriser notre connexion : en autorisant uniquement la connexion de l’utilisateur « root » à l’aide d’une clé RSA !

On coupe court à toutes les attaques de type « brute force » (type d’attaque qui utilise toutes les combinaisons possibles pour se connecter).

– La clé qu’on va générer, il faut vraiment la voir comme la clé d’une maison : si on ne l’a pas, on ne rentre pas. Donc triple backup, s’il vous plaît, ne la perdez pas !

PS : si jamais vous la perdez quand même, il existe en général une console d’urgence chez votre hébergeur qui permet de retrouver son accès en éditant le fichier de configuration de SSH.

– Comme dit précédemment, il est recommandé d’utiliser une authentification basée sur un couple de clés. Pour ce faire, créez la paire de clés en utilisant la commande suivante à partir de votre machine cliente, c’est à dire la machine avec laquelle vous allez vous connecter au serveur :

ssh-keygen -b 8192

– Si la machine utilisée sera sous Windows vous pouvez générer une paire de clé via Putty.

– Une fois le logiciel installé, utilisez l’utilitaire intitulé Puttygen, dans le dossier créé par l’installateur.

– Copiez L’ensemble du texte généré dans la fenêtre du haut, et conservez le dans un fichier texte que vous appellerez public-key.txt. Puis entrer un mot de passe à la ligne Key passphrase.

– Confirmez-le sur la ligne du dessous. Ce mot de passe, il ne faudra pas le perdre : vous en aurez besoin quand vous voudrez charger votre clé privée. Si jamais vous vous faites voler votre clé privée, sans le mot de passe, elle sera tout simplement inutilisable.

– Puis, cliquez sur le bouton Save private key et enregistrez la sur votre ordinateur:

–> Tous ces fichiers doivent être sauvegardés et conservés précieusement, car sans clé, pas de connexion possible.

– Entrez la commande suivante, afin de copier votre clé publique vers le serveur SSH (en écoute sur le port 2021) depuis votre machine cliente :

ssh-copy-id -p 2021 [email protected]

– Bien sûr, l’utilisateur tintin devra s’authentifier afin de pouvoir déposer sa clé SSH. Afin de vérifier que votre clé est bien arrivée sur le serveur SSH, exécutez la commande suivante (vous ne devez plus entrer de mot de passe) :

ssh -p 2021 [email protected]

– Si vous avez généré une paire de clé sous Windows, il va falloir la déclarer sur le serveur manuellement.

Cela va se passer au niveau du homefolder du login qui va se présenter soit ici /home/tintin

– Dans ce répertoire du home, il faut qu’un répertoire .ssh existe et qu’il contienne un fichier nommé authorized_keys

– Donc il faut se logger avec le compte pour lequel on veut s’authentifier avec un certificat et créer le répertoire .ssh avec cette commande

mkdir ~/.ssh

– Pour être certain, déplacez vous dans le répertoire:

cd ~
cd /home/tintin

– Modifier les droits du répertoire .ssh avec la commande:

chmod 700 .ssh

– Entrer dans le répertoire .ssh:

cd .ssh

– Il faut ajouter votre clé publique dans un fichier nommé authorized_keys qui n’existe pas forcément.

– Pour cela on va utiliser la commande echo à laquelle on demandera d’ajouter la clé publique dans le fichier authorized_keys.

La commande écho délimite le début et la fin de la clé par " et "
La clé publique doit être en une seule ligne, sans retour à la ligne etc

– Pour copier la clé publique, dans puttygen, faire un clic droit sur cette dernière et choisir Tout sélectionner

– Refaire un clic droit et copier toute la clé publique:

– Côté serveur, coller la clé publique entre les 2 " "

– La commande à adapter avec votre clé publique est donc:

echo "votreclépublique" >> authorized_keys

– Modifiez les droits de authorized_keys avec la commande

chmod 600 authorized_keys

IMPORTANT: Tester le nouvel accès par clé sans couper la connexion SSH déjà ouverte en cas de soucis.

A. Désactivez l’authentification par mot de passe classique

– Afin de durcir la sécurité de notre serveur SSH, nous allons autoriser seulement la connexion par clé publique/privée.

– Décommentez la ligne suivante dans le fichier et changer la valeur du paramètre PasswordAuthentication de yes à no :

sudo nano /etc/ssh/sshd_config
PasswordAuthentication no

– Puis, redémarrez le service SSH.

sudo systemctl restart ssh

– Si vous tentez de vous connecter sans fournir une clé privée, pour le processus d’authentification, une erreur sera retournée. Pour réaliser ce test, je bascule en root sur la machine cliente Kali, et j’essaie de me connecter :

V. Pour aller plus loin

– Pour aller plus loin, et notamment lutter contre les attaques brutes à destination du service SSH, vous pouvez miser sur Fail2ban ou CrowdSec pour protéger le service. Ma préférence va à CrowdSec qui est bien plus moderne/efficace et léger.

– Voici deux tutoriels qui devraient vous aider :

Et si vraiment SSH est un sujet qui vous intéresse et que vous souhaitez apprendre à le configurer plus précisément, je vous invite à lire notre cours sur le SSH

SOURCES: ITconnect.fr - Tutos.eu

Idylle

@violence
Bonjour,
Bonnes explications ; par contre en ce qui concerne le changement de port ssh, les avis divergent et je te renvoie à la lecture de ce topic:

texte du lien

Ashura

sympa comme tuto

Violence

@Idylle

Je suis plutôt partisan de le changer.
C’est simple, ça ne mange pas de pain et ça évite les scripts de scans auto uniquement sur ce port avec brute force auto sur le port 22

Il existe aussi une autre méthode dites de rebond (J’en parlerais dans un autre tuto) qui te fait passer par une série/séquence de ports avant d’arriver sur le bon grâce à Port Knocking. C’est aussi très efficace.

Tu ajoutes crowdsec/fail2ban/portsentry et tu est quand même relativement tranquille

Idylle

@violence a dit dans [Sécurité] Sécuriser son serveur SSH :

@Idylle

Je suis plutôt partisan de le changer.
C’est simple, ça ne mange pas de pain et ça évite les scripts de scans auto uniquement sur ce port avec brute force auto sur le port 22

Bonjour,
Je reprends les dires de “BRUNO” dans ce topic:

***Pourquoi ne pas changer le port par défaut ?

La première raison est assez évidente : il s’agit de sécurité par l’obscurité. Cela peut ralentir un attaquant et éviter les robots qui font de l’attaque par force brute, mais on pourra toujours trouver sur quel port ce service est en écoute.

La seconde raison est que cela peut devenir un vrai casse-tête pour l’administrateur système. Il va lui falloir penser à préciser le numéro de port pour chacune de ses commandes et de ses scripts. S’il a 50 serveurs avec des ports différents à chaque fois, cela ne va pas être simple. Il peut également arriver d’avoir à utiliser des applications qui ne peuvent se connecter que sur le port standard.

**La troisième raison est que l’utilisation d’un port non privilégié diminue la sécurité**. En effet, n’importe quel utilisateur peut écrire un script qui écoute sur un port non privilégié et ainsi capturer les informations qui transitent par ce port. Seul l’utilisateur root peut utiliser un port <1024.

…/…
Tu trouveras aussi de nombreux blogs ou documentations qui disent la même chose que moi, des exemples pris au hasard : https://serverfault.com/questions/189282/why-change-default-ssh-port ou https://security.stackexchange.com/questions/32308/should-i-change-the-default-ssh-port-on-linux-servers***
########

-Pour la 1° raison, le brute force des robots ne teste que par mots de passe ; et si connexion/clé avec désactivation de la connexion/mot de passe, effectivement BRUNO à raison, le seul bénéfice serait de diminuer les logs, mais peu importe les logs si l’entrée impossible.

-Mais c’est surtout la 3° raison qui me paraît la plus pertinente.

Edit:
A partir du moment qu’une connexion exclusive/clef rsa >=2048 ou ED25519 est considérée comme inviolable avec les moyens actuels, le Port Knocking n’est il pas un gadget ?

https://security.stackexchange.com/questions/4518/how-to-estimate-the-time-needed-to-crack-rsa-encryption
https://superuser.com/questions/881063/how-long-would-it-take-to-break-a-1024-bit-openpgp-encrypted-email

Quant à Fail2ban ou Crowdsec, j’y vois plus leur utilité dans la protection des ports Web dans ce cas.

Violence

@Idylle

J’avais bien lu les dire de ce “Bruno” avant de te répondre. J’en suis désolé mais cela ne me fais pas changer d’avis pour autant.

Première raison: il le dit lui même, cela permet de ralentir une attaque. Je ne vois pas pourquoi s’en priver.
Seconde raison: J’ai déjà été admin dans une boite avec une vingtaine de server. Si l’admin est organisé, il n’y aura aucun casse tête.
Troisième raison: Peut être la plus viable mais est-elle suffisante pour se passer d’un paramétrage si simple.

Le but pour moi est de ne pas savoir qui a raison, qui a tort, c’est pas le concours de ki ka la plus grosse. J’exprime juste mon point de vue et j’imagine que toi aussi.

Pour moi, c’est un un Best Pratice que m’ont appris tout mes formateurs lors de mes études IT et j’y trouve plus de point positif que négatif.
C’est d’ailleurs la première fois en 20 ans qu’on me dit que ce n’est pas bien de le faire.

Mais chacun fait comme il le sent.
Libre à toi de passer outre ce paramétrage.

@idylle a dit dans [Sécurité] Sécuriser son serveur SSH :

Edit:
A partir du moment qu’une connexion exclusive/clef rsa >=2048 ou ED25519 est considérée comme inviolable avec les moyens actuels, le Port Knocking n’est il pas un gadget ?

Plein de gens n’utilisent pas une méthode d’authentification par clés pour pleins de raisons différentes. Ce pourquoi je pense que je présenterais cette méthode à l’avenir ou update celui-ci.

@idylle a dit dans [Sécurité] Sécuriser son serveur SSH :

Quant à Fail2ban ou Crowdsec, j’y vois plus leur utilité dans la protection des ports Web dans ce cas.

Ils te permettent de dégager les intrus qui s’amusent.
Personnellement je n’aime pas savoir que des mecs s’amusent sur mes machines exposées au web et je préfère les dégager à la moindre tentative. Je n’y vois aucun intérêt à les laisser faire.

Ils te permettent aussi de dégager direct une catégorie de gens/IP Range communautaire avant même qu’ils tentent quoi que ce soit notamment avec Crowdsec (c’est aussi un peu le but).

A savoir que Fail2ban/crowdsec n’est pas lié uniquement au SSH. Tu peux protéger bien d’autres choses comme les serveurs web, les moteurs de BDD etc…

Pour ma part, je n’ai plus aucun serveurs exposé au web sans Crowdsec.
Ce genre d’outils est pour moi indispensable.

Ze-lol

@violence a dit dans [Sécurité] Sécuriser son serveur SSH :

@Idylle

Je suis plutôt partisan de le changer.
C’est simple, ça ne mange pas de pain et ça évite les scripts de scans auto uniquement sur ce port avec brute force auto sur le port 22

Il existe aussi une autre méthode dites de rebond (J’en parlerais dans un autre tuto) qui te fait passer par une série/séquence de ports avant d’arriver sur le bon grâce à Port Knocking. C’est aussi très efficace.

Tu ajoutes crowdsec/fail2ban/portsentry et tu est quand même relativement tranquille

Pareil.
Au moins tu évite les scripts kiddies et certains bots.
Avec failban ou mieux Crowdsec par dessus de toute façon c’est verrouillé.

En 15 ans je ne me suis fait avoir que sur des applicatifs web.
Jamais sur un ssh.

Idylle

C’est d’ailleurs la première fois en 20 ans qu’on me dit que ce n’est pas bien de le faire.

Je n’ai jamais dit que ce n’était pas bien de le faire (j’avais même liké ton post sur le plan général avant d’écrire mon premier post sur le sujet) ; j’ai voulu dire que je n’étais pas convaincu de l’apport sécuritaire du changement de port pour celui qui se connecte par clé exclusivement avec l’inconvénient (raison 3) ; après libre à chacun de faire ce qu’il entend.

D’ailleurs ce sujet de l’utilité ou non de ce déport date de plusieurs années:

2012 :
https://adayinthelifeof.nl/2012/03/12/why-putting-ssh-on-another-port-than-22-is-bad-idea/

J’ai deux serveurs, et ça doit bien faire une dizaine d’année que je me connecte en ssh via clé et sur le 22, avec fail2ban au départ, remplacé récemment par crowdsec qui pour moi est plus utile pour le web même s’il couvre en même temps le ssh ; auparavant quand je me connectais/mdp, je délocalisais le port.

Je reste convaincu, que pour celui qui ne se connecte à son serveur que par clé, le risque sur son serveur ne viendra pas du ssh, mais des ports web et des applis derrière, alors dans ce cas pourquoi pas les délocaliser aussi (et avoir du coup un serveur web qui ne serve pas à grand chose).

Violence

@idylle a dit dans [Sécurité] Sécuriser son serveur SSH :

Je n’ai jamais dit que ce n’était pas bien de le faire

Effectivement tu as raison, autant pour moi.

Pour ceux chez qui la méthode du port Knowcking via knock intéresse:

https://doc.ubuntu-fr.org/port-knocking

Violence

Archivé et retranscris dans le wiki

https://wiki.planete-warez.net/fr/informatique/sécurité/secure-ssh

Planète Warez

Light

Dim

Dark

[Sécurité] Sécuriser son serveur SSH

Sommaire

I. Présentation

II. Sécurisation générale de SSH

A. Modifier le port et l’interface réseau d’écoute par défaut

B. Configurer le timeout des sessions SSH

C. Empêcher la connexion de l’utilisateur root en SSH

III. Sécuriser l’authentification par mot de passe classique

A. Autoriser seulement la connexion pour un ou plusieurs utilisateurs.

IV. Authentification par clés publique/privée

A. Désactivez l’authentification par mot de passe classique

V. Pour aller plus loin

I. Présentation

Environnement :

II. Sécurisation générale de SSH

A. Modifier le port et l’interface réseau d’écoute par défaut

B. Configurer le timeout des sessions SSH

C. Empêcher la connexion de l’utilisateur root en SSH

III. Sécuriser l’authentification par mot de passe classique

A. Autoriser seulement la connexion pour un ou plusieurs utilisateurs.

IV. Authentification par clés publique/privée

A. Désactivez l’authentification par mot de passe classique

V. Pour aller plus loin