SSH. Nous le savons. Nous aimons ça. Nous devons l'utiliser.
Je vais vous guider à travers huit étapes pour mieux vous aider à sécuriser le service SSH sur votre réseau. Je pense que nous apprécions tous l'importance de SSH. Il nous permet de nous connecter depuis et vers des appareils Linux, des serveurs Unix, des appareils réseau et parfois même des machines Windows. Je ne vais pas essayer de vous vendre la fréquence d'utilisation de SSH ou son importance. Je vais vous fournir une liste de contrôle solide que vous pouvez utiliser pour vous assurer que les services SSH de votre environnement sont verrouillés.
1. Sauvegardez le fichier de configuration
Tout d'abord, sauvegardez le fichier de configuration avant d'apporter des modifications majeures. C'est un conseil commun, mais c'est un vrai. C'est facile, cela ne prend qu'un instant et vous protège en cas d'erreur lors de l'édition du fichier. Et qui n'a pas fait d'erreur dans Vim ?
# cp /etc/ssh/sshd_config ~/sshd_config_original Vous voyez, ce n'est pas si mal.
Défi - Sauvegardez-vous systématiquement les fichiers de configuration avant d'apporter des modifications majeures ?
2. Définir un message de bannière
Certes, il s'agit autant d'exigences légales que d'autre chose, mais encore une fois, ce réglage ne prend qu'un instant. Vous pouvez également fournir de très bonnes informations dans les messages de bannière. Tout d'abord, nous allons écrire le message de la bannière dans le /etc/issue.net fichier en utilisant Vim. Ensuite, nous ouvrirons le sshd_config fichier et dites-lui d'utiliser le contenu de issue.net comme bannière.
# vim /etc/issue.net
Warning! Authorized use only.
This server is the property of MyCompanyName.com [ Vous pourriez également aimer : Automatisation des mots de passe SSH sous Linux avec sshpass ]
De toute évidence, vous voudrez proposer quelque chose de spécifique à votre organisation. Supprimez toutes les informations qui se trouvent déjà dans issue.net fichier.
Ensuite, dites à SSH d'utiliser le message de bannière. Ouvrez le sshd_config fichier dans Vim, et trouvez la ligne qui lit Banner . Vous vous souvenez que vous pouvez utiliser le caractère barre oblique dans le mode Commande de Vim pour rechercher un fichier par mot-clé, n'est-ce pas ? Par exemple, /banner
# vim /etc/ssh/sshd_config Trouvez la ligne qui lit # aucun chemin de bannière par défaut , puis décommentez la ligne suivante (elle indique Banner ).
# no default banner path
Banner /etc/issue.net Enregistrez vos modifications dans Vim avec :wq puis redémarrez le service SSH :
# systemctl restart sshd Remarque :je ne vais pas vous rappeler de redémarrer SSH à partir de maintenant. Chaque fois que vous modifiez le fichier de configuration, vous devez redémarrer le service.
Défi - Le message de la bannière est-il cohérent sur tous les appareils SSH de votre réseau ?
3. Empêcher les mots de passe vides
Cela semble être une évidence, mais les mots de passe vides sont clairement une mauvaise idée. Vous pouvez avoir d'autres utilitaires, tels que les modules d'authentification enfichables (PAM), qui réglementent vos mots de passe habituels, mais c'est également une bonne idée de vous assurer que SSH applique également des paramètres de sécurité responsables.
Ouvrez le /etc/ssh/sshd_config fichier dans Vim, puis recherchez la ligne qui lit PermitEmptyPasswords . Décommentez-le et remplacez le oui valeur avec non .
PermitEmptyPasswords no C'est tout.
4. Empêcher l'utilisateur root de traverser le réseau via SSH
L'idée ici est assez simple. Envoyez les informations d'identification utilisateur standard sur le réseau au lieu des informations d'identification racine. Une fois que vous avez établi votre connexion SSH à l'aide d'un compte utilisateur standard, utilisez su ou sudo pour élever vos privilèges.
Ouvrez le fichier de configuration SSH, puis décommentez le PermitRootLogin doubler. Modifiez le paramètre de oui à non .
PermitRootLogin no
Défi - votre organisation a adopté sudo , n'est-ce pas ?
5. Ajoutez des comptes d'utilisateurs spécifiques à la liste blanche
Si vous empêchez déjà l'utilisation du compte d'utilisateur root sur SSH, pourquoi ne pas aller plus loin et indiquer explicitement quels utilisateurs peuvent se connecter au serveur ? Peut-être avez-vous un compte administrateur non root régulier que vous utilisez ou un compte déjà configuré avec sudo privilèges.
Dans le fichier de configuration SSH, ajoutez la ligne suivante (elle n'y figure pas par défaut) :
AllowUsers user1 Je le mettrais près du PermitRootLogin no réglage.
Au fait, vous pouvez réellement filtrer avec tous les paramètres suivants :Autoriser les utilisateurs , Refuser les utilisateurs , Autoriser les groupes , Refuser les groupes . Je les ai écrites exprès dans cet ordre—c'est l'ordre dans lequel elles sont traitées. Vous pouvez découvrir plus d'informations sur la page de manuel de sshd_config .
Défi - faites attention à qui est exactement autorisé.
Remarque :Vous pouvez également limiter les connexions via iptables.
6. Plus de port 22
Un autre changement courant consiste à configurer SSH pour écouter sur un port différent du port standard 22/tcp que nous avons tous mémorisé. Il y a déjà une entrée dans le sshd_config fichier.
Vous pouvez commenter le paramètre de port par défaut et ajouter une autre ligne, comme je l'ai fait ci-dessous :
#Run SSH on a non-standard port
#Port 22
Port 2222 Je soupçonne que beaucoup de gens utilisent 2222 comme numéro de port de remplacement, vous voudrez peut-être standardiser sur quelque chose d'un peu plus unique.
Vous devez vous rappeler d'ajouter le nouveau numéro de port non standard à vos tentatives de connexion SSH à partir de maintenant. Par exemple :
# ssh -p 2222 [email protected] Défi :avez-vous le même numéro de port non standard configuré pour toutes vos destinations SSH ? La cohérence vous facilitera grandement la vie.
7. Le temps est écoulé !
L'astuce suivante traite de la temporisation des connexions. L'ClientAliveInterval gère les connexions SSH inactives. Le serveur envoie un message au client et attend une réponse. L'ClientAliveInterval est l'espace de temps entre les messages. Le ClientAliveCountMax définit combien de fois le serveur fera cela avant de décider que le client n'est plus vraiment là. À ce stade, la connexion est interrompue.
Voici un exemple de configuration qui vérifie toutes les 60 secondes et le fera trois fois :
ClientAliveInterval 60
ClientAliveCountMax 3 Modifiez ces valeurs en quelque chose qui a du sens pour votre environnement.
Remarque :Si vous utilisez SSH pour créer un tunnel pour d'autres connexions, vous devrez peut-être vous assurer que l'intervalle est suffisamment long pour prendre en charge correctement les autres applications qui l'utilisent.
Il y a un ServerAliveInterval valeur que vous pouvez également configurer côté client. Cela permet aux clients d'abandonner les connexions aux serveurs SSH qui ne répondent pas.
8. Voici la clé
L'authentification par clé est l'un des paramètres de sécurité les plus courants pour SSH de nos jours. Au fil des années où j'ai enseigné Linux, cette méthode d'authentification est devenue de plus en plus courante. En fait, je ne tenterais pas un examen d'administration Red Hat sans me sentir en confiance dans ce processus. Heureusement, ce n'est pas difficile.
Faisons un examen rapide. L'authentification par clé utilise la cryptographie asymétrique. Cela signifie qu'il y a deux clés, différentes mais mathématiquement liées l'une à l'autre. L'un est privé et n'est jamais envoyé sur le réseau. L'autre est public et peut être transféré sur le réseau. Étant donné que les clés sont liées, elles peuvent être utilisées pour confirmer des identités, telles que des tentatives d'authentification SSH.
Vous devrez générer la paire de clés sur l'ordinateur client SSH local, puis transférer la clé publique sur le réseau vers le serveur SSH de destination. Autrement dit, les clés vous identifieront sur votre poste administrateur. Une fois cette configuration en place, vous n'êtes plus sollicité pour un mot de passe lorsque vous établissez une connexion SSH.
Le processus ne nécessite que quelques étapes.
Tout d'abord, générez la paire de clés :
# ssh-keygen
Les clés sont stockées dans votre répertoire personnel dans un répertoire caché nommé .ssh , et les noms de clé par défaut sont id_rsa (clé privée) et id_rsa.pub (clé publique).
Ensuite, envoyez la clé publique user1 sur le réseau au serveur SSH de destination situé à 10.1.0.42 :
# ssh-copy-id [email protected] Enfin, testez la connexion :
# ssh [email protected] Notez que vous n'êtes pas sollicité pour un mot de passe.
Puisque vous avez maintenant adopté l'authentification par clé, vous pouvez modifier le sshd_config fichier pour empêcher toute connexion basée sur des mots de passe. Une fois ce paramètre configuré, seule l'authentification par clé sera acceptée.
Modifiez ces deux lignes dans le fichier :
PasswordAuthentication no
PublicKeyAuthentication yes [ Vous voulez en savoir plus sur la sécurité ? Consultez la liste de vérification de la sécurité informatique et de la conformité. ]
Récapitulez
J'ai répertorié plusieurs configurations SSH courantes mais efficaces pour vous aider à mieux sécuriser votre environnement. N'oubliez pas qu'avec la sécurité, aucun paramètre n'est susceptible de protéger vos appareils. L'objectif est des couches de sécurité, dont la combinaison aide à atténuer les menaces de sécurité. Je vous suggère fortement d'organiser soigneusement vos clés si vous implémentez l'authentification basée sur les clés. Vous pouvez également envisager d'utiliser un /etc/ssh/sshd_config centralisé fichier pour maintenir des configurations de sécurité cohérentes sur vos serveurs SSH. N'oubliez pas de redémarrer SSH chaque fois que vous modifiez le fichier de configuration.