Je veux savoir ce que je dois faire pour écarter (ou confirmer) une attaque avant de la réparer.
Vous devez utiliser un canal de confiance à 100% pour recevoir ces informations.
La meilleure approche consiste à se connecter directement au système, c'est-à-dire à brancher un clavier et un écran, ou à utiliser une console série si nécessaire.
Une fois que vous vous êtes connecté, exécutez l'une des commandes suivantes :
ssh-keygen -l -f <( ssh-keyscan 127.0.0.1 )
ou :
for k in /etc/ssh/ssh_host_*_key.pub; do ssh-keygen -l -f "${k}"; done
Ce sera :
-
ssh-keyscan - Connectez-vous au serveur SSH du système local et demandez les clés de l'hôte.
- Vous pouvez échanger
127.0.0.1 pour un hôte distant aussi si vous en avez besoin... bien que faire cette opération à distance nécessite une confiance absolue que le distant est bien celui qu'il prétend être, et que tout ce qui se passe entre vous et le distant est digne de confiance.
- Utilisation de
127.0.0.1 acheminera la connexion via l'interface de bouclage, et communiquera directement avec le système local. (en ignorant les potentiels iptables règles de réacheminement du trafic)
- En cas d'attaque, l'utilisation de
localhost peut en fait vous rediriger vers un autre hôte (en utilisant la fonction /etc/hosts ), il faut donc éviter de l'utiliser.
-
ssh-keygen - Montrer les empreintes digitales ( -l ) des clés dans le fichier fourni ( -f ${file} )
- Utilisation avec
ssh-keyscan 127.0.0.1 (c'est-à-dire l'option 1) se connectera au démon en cours d'exécution, et interrogera les clés comme le ferait n'importe quel autre client.
- L'utilisation avec des fichiers dans le système de fichiers local (c'est-à-dire l'option 2) peut être considérée comme la solution la plus simple. plus sûr "mais cela ne tient pas compte d'une mauvaise configuration du serveur, avec des clés situées ailleurs... Il vous faudra aller chercher les bonnes clés.
Ensuite, une fois que vous avez les empreintes digitales, comparez-les soigneusement avec la clé proposée par le système distant auquel vous essayez de vous connecter (par exemple, la clé d'accès à l'Internet) : SHA256:0xgFiU5j9W2WgyurDOgORf+qeFQoHf0YE6G92KnrduY dans votre exemple).
Si l'empreinte digitale ne correspond pas à vous avez alors confirmé qu'une attaque est en cours, et vous ne parlez pas au système que vous pensez être.
Si l'empreinte digitale correspond, c'est génial ! Résolvez le problème en utilisant ssh-keygen -R ${hostname} et continuez votre chemin.
Notes :
- L'avertissement standard selon lequel si un système est compromis, vous devez considérer que la clé hôte l'est également... auquel cas vous n'aurez aucun moyen de le savoir.
- Il est possible de provoquer une collision de hachage et de présenter la même empreinte digitale pour deux clés différentes... auquel cas vous n'aurez aucun moyen de le savoir.
- Tout trafic basé sur le réseau peut être modifié ou redirigé en utilisant
iptables ... si vous soupçonnez qu'un système est comprimé, il peut être judicieux de le vérifier également.
Il est impossible d'y parvenir sans disposer d'un canal de communication fiable à 100 %. Dans votre cas, vous pouvez vous connecter sur le Pi, et récupérer les clés directement. Dans d'autres situations, vous pourriez avoir besoin de " croire la parole d'un collègue "... Faites attention où vous mettez votre confiance.
Je suis novice dans ce domaine et je veux exclure toute attaque de type "man-in-the-middle".
Sur un petit réseau local, c'est très que vous parlez au système que vous pensez être.
Si l'adresse IP distante se trouve dans votre sous-réseau et qu'il n'y a pas d'autres appareils inconnus ou suspects dans votre réseau, il sera difficile de construire une attaque MITM. Pour plus de certitude, essayez de supprimer tous les autres appareils, ou même de créer un lien point à point entre votre ordinateur et l'ordinateur distant (bien que l'adressage et le DHCP puissent devenir problématiques dans cette situation).
Si vous pensez que votre routeur n'est pas digne de confiance, n'oubliez pas qu'il peut annoncer des routes et des noms (DNS / mDNS / WINS) à votre système, auquel votre système fera généralement confiance implicitement. Si Internet peut être retiré de l'équation, alors de telles astuces de routage / redirection ne peuvent pas être jouées à moins qu'elles ne soient facilitées en interne.
... " La confiance dans l'informatique "C'est un très grand sujet, et il y a tellement de pistes que nous pourrions vous envoyer ici... Je vous encourage à demander / lire / jouer / etc... c'est la meilleure façon d'apprendre.
Comme cela a déjà été discuté dans d'autres réponses... la situation la plus probable dans laquelle vous vous trouvez ici est l'une ou l'autre :
- Vous avez réinstallé le système d'exploitation sur votre Raspberry Pi.
- Votre serveur DHCP a transmis un bail qui avait été donné à un autre hôte que vous avez utilisé.
ssh avec, et qui a été récemment donné à votre Raspberry Pi
En général, les gens acceptent l'empreinte digitale affichée lors de la première connexion et s'en contentent à l'avenir.
Sur les systèmes particulièrement sensibles, vous voudrez confirmer que l'empreinte digitale est exactement correcte lors de la première connexion.
Si l'empreinte digitale change, c'est que quelque chose a changé sur l'hôte, par exemple un imposteur ou une réinstallation.
