La partie difficile pour tout administrateur informatique est de trouver la bonne solution pour sécuriser les données. Lorsqu'il s'agit de sécuriser le serveur SSH, tout le monde veut tester la solution et voir les fonctionnalités exactes qui sont également très importantes.

Cette page montre comment sécuriser votre serveur OpenSSH s'exécutant sur un système d'exploitation Linux/Raspberry et tester dans un environnement temps réel.

Que fait SSH ?

SSH offre deux fonctions principales :

• En vous connectant à des systèmes distants et en exécutant des sessions de terminal, exécutez des commandes distantes et autres sur ces systèmes distants.
• Transfert de fichiers entre systèmes distants.

Voici notre top 7 pour savoir comment sécuriser votre Open SSH :

1) Utilisez des connexions basées sur la clé publique SSH

L'authentification par clé publique associée à des identités centralisées dans un backend LDAP est la méthode d'authentification la plus forte pour les serveurs OpenSSH. 

Générez une paire de clés à l'aide de la commande ssh-keygen suivante à partir de votre machine Linux, Mac ou Windows. 

Vous pouvez soit générer la paire de clés sur votre ordinateur de bureau/ordinateur portable local, soit importer uniquement la clé publique sur votre compte LDAP.

Pour générer la paire de clés, la commande standard pour tous les systèmes est ssh-keygen, elle vous invite à entrer le chemin d'accès au fichier dans lequel vous souhaitez enregistrer la clé.

Un chemin et un nom de fichier par défaut sont suggérés entre parenthèses. Par exemple : /accueil/Nom d'utilisateur/.ssh/id_rsa. 

 

Avec Solutions RCDev, vous avez accès au libre-service. Ici, les utilisateurs peuvent générer eux-mêmes la nouvelle paire de clés ou importer leur clé publique existante afin d'utiliser leur clé privée existante à des fins de connexion SSH. Même les clés matérielles FIDO et PIV peuvent être utilisées pour vos connexions SSH. 

Les clés publiques n'ont pas besoin d'être déployées sur chaque serveur SSH ! Un agent est à la place installé et l'agent vérifiera auprès du serveur si la clé privée fournie lors de la connexion SSH correspond à la clé publique stockée sur les comptes des utilisateurs.   

 

 

 

Avec les solutions RCDevs, la gestion/déploiement des clés SSH est entièrement automatisé depuis la génération de la paire de clés, en passant par la révocation des accès (sur tout ou un groupe de systèmes en un seul coup pour un utilisateur), jusqu'au renouvellement automatique par les utilisateurs finaux d'un clé expirée. 

 

 

Suite informations au WebADM 

Plus d'informations sur la sécurisation gratuite du serveur SSH

Documentation d'intégration

2) Activer l'authentification multifacteur

L'activation de l'authentification multifacteur (MFA) sur les machines Linux est également l'un des moyens éprouvés de sécuriser votre serveur SSH.

Vous pouvez implémenter une connexion simple ou une connexion push pour MFA.

L'image ci-dessous montre le flux de connexion pour MFA dans SSH Server.

 

 

Sur les systèmes de type Unix, des processus tels que le démon OpenSSH doivent authentifier l'utilisateur et apprendre certaines choses à son sujet (ID utilisateur, répertoire personnel). L'authentification se fait via un mécanisme appelé Pluggable Authentication Modules, et la récupération d'informations sur les utilisateurs (ou même les groupes, les noms d'hôtes) se fait via un autre mécanisme, appelé Name Service Switch.

Lire Comment implémenter MFA dans SSH Server / PAM

3) Gérez de manière centralisée vos clés et comptes SSH

 

De nombreuses, voire toutes, les connexions Unix et Linux ne sont pas gérées, sans la possibilité de déterminer quelle clé appartient à quelle identité et si l'accès est en infraction avec les directives IAM de l'entreprise. En pratique, cela signifie qu'une identité inconnue peut se connecter avec une clé dont l'existence n'est même pas connue. Pour aggraver les choses, les connexions SSH sont généralement destinées à un accès privilégié, qui est la forme d'accès la plus critique.

La solution est de centraliser les clés SSH et comptes. Il est également recommandé d'utiliser l'inscription Web en libre-service pour automatiser la distribution des clés et auditer les accès indésirables ou le renouvellement des clés obsolètes.

4) Désactiver l'accès SSH avec le compte root

Le compte racine sur les systèmes Linux est le premier compte auquel un attaquant tentera d'accéder en raison des autorisations accordées à ce compte.

Dans la configuration SSH, vous pouvez autoriser la connexion root ou non.

 

 

Il est possible de fournir un accès privilégié aux utilisateurs via le mécanisme SUDO. SUDO offre la possibilité de lancer une commande en tant qu'administrateur (comme root), ou en tant qu'autre utilisateur tout en gardant la preuve des commandes exécutées. SUDO offre la possibilité d'autoriser une action à un utilisateur ou à un groupe d'utilisateurs (mettre à jour un système par exemple) sans leur fournir un accès complet au système.

L'accès au compte root via SSH est fortement déconseillé, mais au cas où vous auriez besoin de l'autoriser, vous devez autoriser l'accès à distance à ce compte avec une authentification par clé publique, couplée à un mot de passe à usage unique (OTP) / Yubikey / validation du mot de passe vocal .

5) Configurer le délai d'inactivité et l'intervalle de session

Un utilisateur peut se connecter au serveur via ssh et vous pouvez définir un intervalle de délai d'inactivité et une durée de session pour éviter les sessions ssh sans surveillance.

 

Vous définissez un intervalle de délai d'inactivité en secondes (300 secondes == 5 minutes). Une fois cet intervalle écoulé, la session SSH est verrouillée et demandera à l'utilisateur de fournir son mot de passe LDAP.

6) Modifier le port SSH par défaut 

L'un des principaux avantages du changement de port et de l'utilisation d'un port non standard est d'éviter d'être vu par des analyses occasionnelles. Il existe un port par défaut pour tous les services. Ainsi, si le numéro de port est modifié, il est difficile de détecter quel service s'exécute derrière ce port et, par conséquent, vos chances d'être attaqué sont réduites.

7) Fixez une limite aux tentatives de mot de passe

En fixant une limite à vos tentatives de mot de passe pour la connexion SSH, vous pouvez réduire l'attaque par force brute sur votre serveur. Certaines des bonnes pratiques dans le cadre de l'utilisateur pour réduire l'accès contraire à l'éthique peuvent être :

-Bloquer les adresses IP avec plusieurs demandes en peu de temps.

-Bloquer les tentatives de connexion pour les utilisateurs avec plusieurs mots de passe erronés.

-Définition d'un intervalle de temps entre les tentatives de connexion au serveur SSH.

Conseils bonus de RCDevs

RCDevs prend en charge 3 couches de sécurité, à savoir la connexion basée sur la clé publique SSH, l'authentification multifacteur et le mot de passe LDAP pour se connecter.

Certaines des fonctionnalités de sécurité prises en charge et recommandées par RCDevs pour une connexion sécurisée sont :

1) Commandes SUDO

Le Commande SUDO définit au niveau de l'utilisateur, du groupe, du système et du réseau, quelles actions peuvent être effectuées par eux en fonction des privilèges définis et déployés.  

 

2) Blocage des utilisateurs

Le blocage des utilisateurs est très utile pour empêcher les attaques par force brute. Vous pouvez définir un nombre maximal d'essais de connexion, une minuterie de blocage des échecs, des alertes de blocage à l'administrateur, une durée maximale de session, une durée de verrouillage de l'écran, etc.

Vous pouvez également autoriser les accès des utilisateurs en fonction des adresses IP, des certificats clients et même des politiques client.

3) Politique du serveur

La stratégie de serveur vous permet d'appliquer le type de clé que l'utilisateur doit utiliser (RSA, ECC ou DSA), la longueur de la clé, l'expiration de la clé et l'utilisation maximale de la clé.

Exemple– Vous souhaitez appliquer l'expiration de la clé après 1 mois à compter de la génération. Vous pouvez simplement sélectionner les jours dans l'onglet Expiration de la clé comme dans l'image ci-dessous.

4) Accès basé sur des balises

L'accès de l'équipe peut être basé sur des balises déléguées par utilisateur ou groupe.

Tous les hôtes gérés par SpanKey Server peuvent être marqués dans la configuration du client SpanKey. Par exemple, tous les serveurs Web pourraient être étiquetés avec l'acronyme « WEB » dans le fichier de configuration du client SpanKey. Ensuite, vous pouvez ajouter cette balise pour tous les comptes ou groupes Webmaster afin de garantir un accès SSH à chaque serveur Web avec une configuration centralisée commune.

5) Facteur de connexion supplémentaire

Vous pouvez également ajouter un facteur d'authentification supplémentaire pour la connexion SSH et le transfert de fichiers SCP/SFTP. (mots de passe LDAP/OTP)

Le facteur de connexion supplémentaire pour la connexion SSH est également possible avec l'authentification biométrique FIDO ou VOICE.

6) Notification de l'utilisateur

Vous pouvez informer vos utilisateurs par courrier ou SMS si sa paire de clés ou son mot de passe LDAP va expirer. En plus de cela, vous pouvez configurer le serveur SpanKey pour envoyer automatiquement des demandes d'accès en libre-service pour accéder aux différents portails lorsque SpanKey détecte que le mot de passe des utilisateurs ou la paire de clés SSH a expiré.   

7) Mode hors ligne

Une autre caractéristique intéressante de SpanKey est le fait que même si les serveurs SpanKey sont en panne pour une raison quelconque et que les authentifications ne peuvent pas être vérifiées avec le serveur, vous pouvez configurer des comptes spécifiques qui peuvent être utilisés en mode hors ligne. De cette façon, vous pouvez toujours accéder à vos serveurs SSH même si le serveur SpanKey ne répond plus.

Vous pouvez Télécharger la solution de gestion de clés SSH RCDevs Security Solutions maintenant et obtenez jusqu'à 5 hôtes Spankey gratuitement.