Boîte d'astuces: Sanctuariser SSH – mais correctement!
SSH? Jelenaipasbesoin – j'ai Telnet...
Cette façon de voir peut être valide dans un milieu
sanctuarisé (p. ex. dans un réseau privé sans connexion
directe d'extérieur), mais lorsqu'une connexion à
travers l'Internet est necessaire, elle est extrêmement dangereuse.
Il y a un problème, parce que Telnet établira une connexion
insécure que peut être examiné à tout moment en
route de votre ordinateur à sa destination. Vous avez un problème
s'il y a un ordinateur en route qu'est déraillé et
examine le trafic de données.
On pourrait arguer que cet ordinateur n'a pas l'adresse
réseau correcte et donc ne peut pas être le receveur – mais elle a
une faculté à la configurer à une façon
qu'elle réagit à toutes
données par paquets qu'elle obtient, qu'elle est le
récepteur ou non: C'est appelé
promiscuous mode. Ce mode a une raison
d'être (diverses fonctions du réseau ne seraient pas possible
sans ce mode), mais malheureusement il offre la possibilité d'abus.
Menace pour la sécurité: Texte clair
Comme la phrase indique: On peut examiner l'entier trafic de
données en route d'un ordinateur à l'autre sans des
mesures appropriées. Certes ils ne réagiront pas au trafic de
données, mais des problèmes resultent lorsqu'il est
enregistré sur quelconque relais.
Il se peut révéler benin, parce que potentiellement
quelqu'un cherche des défauts ou des autres problèmes, mais
il serait possible que quelqu'un cherche les données
confidentielles (p. ex. des identificateurs d'accèes, c'est
nom d'utilisateur et mot de passe, des coordonnées bancaires, ou
des autres données pas destinées au grand public) – et
l'intention n'est pas bon du tout.
Pour éviter une mauvaise surprise, il est necessaire de rendre le trafic
de données méconnaissable. Car personne ne peut reconnaître
rien, personne ne va pas fouiner.
Menace pour la sécurité: Destination de la connexion
Probablement vous vous demanderez pourquoi précisément
ça serait un problème. Il y a
finalement une allocation des adresses IP et les destinations des
connexions...
Mais comme souvent, le diable se cache dans les détails.
Comme déjà remarqué, il y a une facilité pour
dérouter le trafic de données à des autres ordinateurs
(promiscuous mode de la carte réseau), sans parler de contrefaire les
adresses (address spoofing).
Pour éviter tomber de Charybde en Scylla, on a besoin de quelque
possibilité à vérifier l'authenticité de la
destination. Car on peut être sûr qu'on est connecté
avec la destination correcte, il n'a pas besoin de s'en faire pour
les événements bizarres.
Pourquoi faire grand bruit?
C'est d'une grande simplicité: Il concerne la
sécurité dans l'Internet. Parce qu'on veut travailler
sécurement à travers l'Internet, on doit veiller à ce
qu'on obtienne une connexion à la destination correcte
premièrement, et deuxièmement personne ne peut pas suivre ce
qu'a lieu sur la connexion.
Seulement comme ça il est assuré qu'on peut travailler
sécurement à travers l'Internet.
Ça c'est l'approche de SSH. On ouvre une connexion que ne
permet pas que l'authentification de l'utilisateur, mais
vérifie l'authenticité de la destination aussi et fait en
sorte que le trafic de données entre l'utilisateur et sa
destination soit chiffré.
Chiffré, mais...
SSH possède, comme on a découvré, des facultés énormes que se veillent à la sécurité du travail, mais un bémol se reste cependant: L'authentification de l'utilisateur. Généralement une combinaison du nom d'utilisateur et mot de passe est employée, mais les éventuels attaquants souvent essaient découvrir le mot de passe – malheureusement dans certains cas elle porte ses fruits...
en hautMenace pour la sécurité: Mot de passe
Dans trop des cas, le mot de passe constitue un problème.
Malheureusement des mots que peuvent être
découvrés par une attaque dictionnaire sont utilisés, résultant de
l'accès à le système par l'attaquant rapidement.
Dans des autres cas des mots de passe qu'on peut
trouver autrement (nom de l'animal domestique, nom de naissance, nom des
parents, etc.) sont choisés.
Mais les meilleures préventions de sécurité n'on
servent à rien lorsque l'interface pour l'utilisateur, soit
l'authentification, est le point faible dans l'entier système.
En effet on n'a rien gagné, et l'attaquant se trouve sur
l'ordinateur rapidement encore une fois.
Donc on a besoin d'une autre méthode que prend une plus
sécure authentification à sa charge, et SSH viens en aide
à nous.
Préparations
Pour défendre contre les attaques dictionnaire et la plupart des
attaques brute-force, nous avons
besoin de quelque chose qu'on ne peut pas contrefaire au pied levé.
Générez une paire des clés RSA que vous pouvez utiliser
comme l'information authentificant pour SSH.
Ouvrez une shell et entrez la commande suivante:
ssh-keygen -t rsa -f id_rsa
Vous pouvez aussi facilement générer les clés ici.
Le logiciel vous demande d'une phrase de passe que sécoure la
clé privée. Lorsque vous êtes la seule personne qui utilise
votre ordinateur, vous pouvez simplement appuyer
Entrée. Aux autres fois entrez quelque
chose ici (peut être à une longueur facultative, mais vous le
devriez retenir encore!) et affirmez la phrase de passe.
ssh-keygen crée la paire des clés.
Ainsi vous recevez deux fichiers:
id_rsa et
id_rsa.pub.
Le fichier id_rsa contient la clé privée
que reste sur votre ordinateur. Copiez-la au répertoire
~/.ssh.
L'autre fichier, id_rsa.pub, doit être
déplacé sur votre ordinateur distant. Effectuez la commande
suivante:
scp id_rsa.pub root@<hostname>:/etc/ssh/authorized_keys
(remplacez <hostname> par le nom effectif de votre ordinateur distant)
Confirmez par le mot de passe pour root sur
l'ordinateur distant et la clé publique est transmis.
Si vous voulez importer une nouvelle clé sur votre ordinateur après vous avez déjà installé quelques clés, vous ne devez pas simplement copier la nouvelle clé en aucune circonstance au ~/.ssh/authorized_keys, come ça va écraser les vieilles clés!
Au lieu de ça copiez-le au /root et transposez-le à l'autre fichier manuellement!
Observez, s'il vous plaît, que vous ne devez pas mettre plusieurs clés dans une ligne pour éviter des problèmes.
Maintenant vous avez conclué les préparations pour renforcer la
sécurité du SSH.
Si vous avez déjà activé l'authentification par des
clés RSA, vous vous ne pouvez pas connecter par nom d'utilisateur
et mot de passe, mais il est impératif que vous donnez la phrase de
passe de la vieille clé pour transmettre des données ou vous
connecter! Autrement SSH refusera la connexion.
La bonne configuration
Après vous avez créé les clés RSA et les transmis
sur les ordinateurs correctes, il les faut configurer correctement. Il y est
nécessaire d'dapter les fichiers configuration non seulement sur votre
ordinateur local, mais aussi sur votre ordinateur distant.
En premier, examinez le fichier configuration pour le client SSH sur votre
ordinateur:
- Ouvrez une shell avec les privilèges root.
- Changez au répertoire /etc/ssh.
- Chargez le fichier ssh_config dans votre éditeur.
- Cherchez les lignes contenant l'expression IdentityFile.
- S'il n'est pas fait, activez la ligne (éliminez-y le symbole #) et sauvegardez le fichier ensuite.
A l'après, le client SSH considéra la clé
annoncée comme ça pour une authentification par les clés
RSA. A propos, vous pouvez annoncer plusieurs clés comme ça,
p. ex. si vous possédez des autres ordinateurs distants (quelconques
serveurs, p. ex.). Simplement insérez une autre ligne contenant
IdentityFile pour toute nouvelle clé.
Ensuite il y a plusieurs changements que sont necessaire sur votre ordinateur
distant.
- Connectez-vous à votre système distant comme root (utilisez le mot de passe correspondant pour connecter).
- Changez au répertoire /etc/ssh.
- Chargez le fichier sshd_config dans votre éditeur.
- Cherchez les mots dans le tableau suivant et adaptez-les comme cité. S'il est necessaire, éliminez le symbole # au début de la ligne.
- Sauvegardez le fichier et sortez l'éditeur.
- Faites SSH adopter toutes les changements.
Ensuite votre serveur SSH est prêt, et des attaquants possibles ont la vie plus dure à l'avenir en s'introduissant sur votre ordinateur.
Paramètres pour le travail sécure avec SSH | ||
---|---|---|
Paramètre | Valeur | Explication |
Protocol | 2 | Spécifie quel protocole SSH doit appliquer. La version 2 (la valeur implicite) est la variante plus sécure. |
PubkeyAuthentication | yes | Permet l'authentification par les clés générées. Parce que cette méthode est plus sécure comme l'authentification par nom d'utilisateur et mot de passe, veuillez l'activer, s'il vous plaît. |
AuthorizedKeysFile | .ssh/authorized_keys | Spécifie le fichier que contient les clés pour connecter.
Pour obtenir la sécurité maximale, laissez la valeur par
défaut, d'autant qu'elle permet les autres utilisateurs
d'importer leurs propres clés. ATTENTION: Si vous changez ce chemin d'accès, vous devez déplacer le fichier authorized_keys à son nouveau endroit et (si vous avez choisi un autre nom en outre) le renommer. Autrefois vous allez vous enfermer dehors! |
HostbasedAuthentication | no | Comme PubkeyAuthentication, mais les fichiers ~/.ssh/rhosts et /etc/hosts.equiv sont extraits aussi. Comme vous travaillez avec une adresse IP dynamique, vous vous fermerez dehors comme ça, donc cette option n'a pas de sens. |
PasswordAuthentication | no | Vous voulez une méthode sécure pour connecter, donc des méthodes insécures doivent être inactivées plus simplement. Changez cette option à no (valeur par défaut serait yes). |
ChallengeResponseAuthentication | no | Est souvent basée sur l'authentification par nom d'utilisateur et mot de passe. Doit être inactivée aussi. |
UsePAM | yes | Même si vous avez inactivé les possibilités de la connexion par mot de passe et challenge-response, le module PAM offre des services aidants par effectuer quelques vérifications si quelqu'un veut connecter. |
Enfin vous devez faire le serveur SSH appliquer les changements. Effectuez une de ces deux commandes:
- Sous System V init (le défaut jusqu'à openSuSE 11.4 inclus): rcsshd reload
- Sous systemd (le défaut à partir de openSuSE 12.1): systemctl reload sshd.service
Sauvegardez votre clé privée en tout cas! Si vous la perdez, vous n'auriez aucune chance de connecter à votre ordinateur comme ça!
Alternativement vous auriez une autre possibilité de connecter (par exemple Telnet dans un tunnel IPsec ou – si votre domicilieur l'offre – une console à distance) en cas de besoin!
en haut
Attaquants – enfermé dehors!
Par l'ajustement de la configuration du SSH vous avez déjà
veillez à la sécurité sur votre ordinateur. En combinant
avec SuSEfirewall2 vous pouvez mener une vie
vraiment dur à des attaquants
possibles!
Vous devez simplement compléter le fichier
/etc/sysconfig/scripts/SuSEfirewall2-custom appropriément. J'ai décrit
détaillé les changements nécessaires sous le
sujet pare-feu.
Si quelqu'un essaie une attaque brachiale à votre ordinateur
distant, il découvrira qu' il est enfermé dehors de bouche
à bouche, et lorsqu'il l'outre, il devra attendre qu'il
puisse recevoir une réaction. En tout cas, le serveur SSH n'est pas
affecté par ces connexions invalides.
Et si comme toute attente vous êtes arrêté dans vos
préventions de sécurité, n'avez pas de la panique.
Simplement attendez les deux heures de blocage et repetez votre essai – ou
créez une autre possibilité de connecter (p. ex. Telnet dans une
tunnel IPsec).