Un ordinateur fonctionne sous Ubuntu avec le cryptage du dossier personnel. Il est allumé mais n'est pas connecté. Un autre ordinateur s'y connecte par SSH, ce qui permet de parcourir le dossier personnel via le terminal. Un pirate ayant un accès physique peut-il maintenant lire les données du dossier personnel ?
Réponses
Trop de publicités?Je ne fais que deviner mais je dirais que non parce que d'abord le pirate doit passer la sécurité de l'OS comme votre mot de passe sur votre ordinateur et pour cela il doit soit connaître le mot de passe soit essayer de craquer le mot de passe pour cela je dirais qu'il doit éteindre l'ordinateur et charger un OS à partir d'un usb donc s'il connaît le mot de passe cela n'a pas d'importance et vous ne pourrez pas faire de ssh s'il charge un OS à partir d'un usb.
Quant au fait que vous lisez vos fichiers pendant que vous utilisez ssh et que vous lisez des fichiers, en se basant sur ce le dossier personnel n'est jamais entièrement décrypté et les données décryptées ne sont jamais stockées sur le disque dur, mais uniquement dans la mémoire vive. Un pirate pourrait être en mesure d'obtenir quelque chose à partir de la mémoire vive, mais il ne s'agirait pas de l'intégralité de votre dossier personnel et je pense que pour le faire, il faudrait éteindre votre ordinateur. (c'est à cela que je fais référence) pour le faire et je ne pense pas qu'il serait facile de lire une mémoire brute.
Je ne pense pas que je serais trop inquiet s'ils ont accès à votre ordinateur, il y a probablement des moyens plus faciles d'obtenir les informations stockées sur le disque dur.
Update
L'ensemble du disque dur étant décrypté lorsque vous vous connectez via ssh, si le pirate parvient à passer la sécurité du système d'exploitation, en vous connectant, vous lui donnez accès à vos fichiers.
があります。 root
a un accès complet à tous les dossiers personnels chiffrés tant que ces utilisateurs sont connectés. Une personne ayant un accès physique à l'ordinateur peut modifier le noyau pour se donner un accès root et accéder aux fichiers de cette façon.
Le serveur SSH peut voir tous les mots de passe saisis, et l'exécutable du serveur SSH peut être modifié par une personne ayant un accès physique pour lui fournir le mot de passe.
Une personne qualifiée ayant un accès physique à la machine peut installer un keylogger (dispositif physique) et accéder à votre dossier personnel après que vous vous soyez connecté localement sur cette machine, à nouveau. En général : Une personne qualifiée ayant un accès physique à votre machine ... qu'entendez-vous par "ma machine" ? Ce n'est plus votre machine.
Cependant, ce qui vous intéresse probablement plus : Votre dossier personnel ne devient pas accessible lorsque vous vous connectez via SSH.
Vous devriez probablement vous assurer que vous pouvez vous connecter, car dans la configuration par défaut, les clés publiques autorisées sont stockées dans le dossier de l'utilisateur. ~/.ssh/authorized_keys
qui ne peut bien sûr pas être lu si votre dossier personnel n'est pas accessible au moment de la tentative de connexion. Si vous modifiez la configuration, vous pouvez vous connecter via l'authentification par clé publique mais votre dossier personnel ne devient pas accessible car votre système ne connaît pas vraiment votre mot de passe.
Si vous vous connectez par mot de passe (ce que vous ne devriez pas faire !), vous donnez votre mot de passe à votre système mais, à ce jour, votre dossier personnel n'est toujours pas accessible. Pour que cela se produise, vous devez exécuter :
ecryptfs-mount-private
S'il devient automatiquement accessible, vous n'avez bien sûr pas besoin d'exécuter cette commande.
Supposons donc que vous ayez réussi à vous connecter et que votre dossier personnel soit accessible.
Si nous excluons les capacités très avancées de l'attaquant, il ne peut toujours pas accéder à votre dossier personnel à moins de pouvoir se connecter à la machine en utilisant un compte quelconque.
Si l'on n'exclut pas que les capacités de l'attaquant soient très avancées, il peut par exemple obtenir vos données et même votre clé de chiffrement via une attaque de cold boot . D'autres attaques sont possibles, mais elles sont nettement moins redoutables (par exemple, arrêter votre serveur et démarrer un système d'exploitation qui démarre à son tour le système d'exploitation habituel de votre serveur, mais qui garde le contrôle total de votre serveur et peut lire la RAM comme il le souhaite ; ou encore, l'attaquant peut modifier certaines parties de votre système d'exploitation pour lui renvoyer des données lorsque vous rendez votre dossier personnel accessible la fois suivante).
Cependant, il est beaucoup plus probable qu'un attaquant installe simplement un enregistreur de frappe que de mener une attaque avancée.