Linux? - Page 215

Il reste que, si l'identification via Cryptsetup peut être contournée, le chiffrement des fichiers en eux-mêmes n'est pas directement affecté.

l'honneur est sauf. bon ok t'as un shell single user root, tu peux niquer le disque, mais pas monter le disque chiffré.

ouais enfin tu peux le recopier tranqulle et partir sans laisser de traces, ensuite, tu peux bruteforcer ta copie...

IIRC le chiffrage linux est quand même bien foutu. tu SAIS que c'est chiffré (contrairement a TrueCrypt), mais pour le récupérer macache, je connais pas d'exploit. les défauts de key derivation et algo utilisé doivent dépendre des distro, mais sous mint c'est

D'autre part on peut faire du full disk encryption y compris le /boot, mais il faut démarrer sur clé usb, ce qui est pas con pour un mode parano.

Oui, c'est comment sous Mint ?

C'est

vince (./6423) :
ouais enfin tu peux le recopier tranqulle et partir sans laisser de traces, ensuite, tu peux bruteforcer ta copie...

Je pense que le bruteforce reste vraiment compliqué. Par contre, en quelques secondes d'accès physique et sans outil, on peut pourrir le boot pour laisser un keylogger (pour déchiffrer plus tard le disque) ou n'importe quel malware.

squalyl (./6422) :
l'honneur est sauf. bon ok t'as un shell single user root, tu peux niquer le disque, mais pas monter le disque chiffré.

vince (./6423) :
ouais enfin tu peux le recopier tranqulle et partir sans laisser de traces, ensuite, tu peux bruteforcer ta copie...

Pire que ça : tu peux installer un programme qui sera lancé en root lors d'un démarrage ultérieur où les disques cryptés seront montés et accessibles, qui pourra transférer les contenus cryptés (soit via le réseau, soit sur un périphérique non crypté auquel on pourra accéder ultérieurement de la même façon), et même s'auto-détruire a postériori pour ne pas laisser de trace... ça a l'air super cool comme faille

edit : cross avec Flan !

certes, anéfé. il faut un firewal openoffice.

sous mint c'est

c'est par défaut chiffré en AES XTS, et la clé est dérivée par > 200k itérations de sha-1 (requises pour transformer le password en clé, ca ralentit le brute force). On peut faire mieux mais c'est en pratique inviolable.

a ma prochaine install je ferai du FDE boot compris avec déchiffrement grub et sha512 mais je savais pas faire quand j'ai installé mon système actuel.

Non ce n'est pas inviolable. C'est difficile avec la puissance brute actuelle (en tout cas avec un seul ordi, meme si je pense que le GPGPU doit bien aider) mais clairement pas inviolable.

Si tu as assez de moyens pour avoir une ferme de machine bien puissante, je pense que ça doit pouvoir s'ouvrir en un temps raisonnable.

Mais en soi, aucun chiffrement n'est inviolable quand on parle de brute force, non ? J'ai l'impression que c'est le sempiternel problème du boulet et de la cuirasse, avec ici comme point clé ce que tu appeles "le temps raisonnable", qui peut s'exprimer en secondes/minutes/jours/années suivant le système cible.

Oui c'est exactement ça, aucun moyen de cryptage n'est inviolable, le seul point a prendre en compte c'est le temps a un instant T qu'il faut pour casser le dit code, et le temps pour lequel les donnes a crypter doivent être protéger.

Si on considère qu'il faut 6 mois pour casser la clef et que de toute façon les information seront inutiles dans 4 mois ce n'est pas un problème. Si il faut que les informations soit garde secrète sur les 10 ans a venir, ça va être un problème.

2^128 n'est pas faisable avec les appareils actuels.

ca fait 2^64 fois 2^64, soit, en décimal, 18 446 744 073 709 551 616 fois 18 446 744 073 709 551 616

edit : huhu http://www.unc.edu/~rowlett/units/large.html

squalyl (./6433) :
2^128 n'est pas faisable avec les appareils actuels.

Sauf qu'il y a certaines choses qu'on ne souhaite pas voir décryptées, même dans 40 ans
Et que ça ne répond pas au problème de l'accès aux données par un logiciel espion (ou de l'accès à la clé avec un keylogger) après un redémarrage.
Ni les fois où la clé est en clair dans le fstab (si, si, évidemment que ça existe...).

le pire est le keylogger, mais en full disk encryption apapossib.
le problème est le boot en clair.

sur un système bien fait, t'as un mdp grub qui déchiffre /boot, et le /boot/initrd qui contient un fichier clé pour déchiffrer /.

le shell en cas d'erreurs répétées est dans tous les cas une abomination. je vais surveiller les maj, mais encore une fois ca concerne les cas du boot en clair.

vince (./6423) :
ouais enfin tu peux le recopier tranqulle et partir sans laisser de traces, ensuite, tu peux bruteforcer ta copie...

Si tu as accès physique à la machine, tu peux emmener le disque carrément. Ou si tu ne veux pas laisser de traces, tu le démontes, tu le recopies avec un boîtier adaptateur USB pour disques SATA (ça coûte moins de 5€) et tu le remets en place.

squalyl (./6424) :
D'autre part on peut faire du full disk encryption y compris le /boot, mais il faut démarrer sur clé usb, ce qui est pas con pour un mode parano.

Euh non, pas besoin de démarrer sur clé USB pour crypter /boot. La seule chose qui ne doit pas être cryptée est GRUB, vu que c'est lui qui demande le mot de passe. Et donc tu peux crypter /boot aussi, parce que GRUB est soit dans la partition système EFI (une partition /boot/efi séparée), soit pour le mode BIOS legacy, dans une partition dédiée (GRUB BIOS boot partition, sur GPT) ou dans le MBR (vieilles tables de partition MBR/DOS).

Cf. aussi https://github.com/calamares/calamares/wiki/LUKS-Deployment.

flanker (./6427) :
Par contre, en quelques secondes d'accès physique et sans outil, on peut pourrir le boot pour laisser un keylogger (pour déchiffrer plus tard le disque) ou n'importe quel malware.

Où veux-tu mettre ton keylogger si tout est crypté? Et si tu y arrives, alors il suffit aussi de démonter pour mettre ton keylogger.

C'est débile de refuser un shell à quelqu'un qui a un accès physique à la machine, ça ne sert à rien niveau sécurité.

"il suffit de démonter" t'as jamais vu un cadenas sur un PC ?

C'est sur que de pouvoir changer le contenu des script non ce n'est pas grave du tout..

Et oui on peux truover des cadenas sur les machines, ou la partie ecran/clavier n'est pas colle a la machine qui peux etre dans une boite dur a deplacer, voir dans la piece d'a cote auquel on a pas acces (c'est extreme mais ca se fait)

squalyl (./6435) :
sur un système bien fait, t'as un mdp grub qui déchiffre /boot, et le /boot/initrd qui contient un fichier clé pour déchiffrer /.

Ce n'est pas toujours jouable, typiquement lorsque la machine n'est pas accessible physiquement (ou semi-physiquement via un superviseur de VM) et qu'un redémarrage sans intervention humaine doit être possible. Je suis d'accord avec toi que ça reste une faiblesse dans la chaîne de cryptage, mais ça arrive (et c'est fréquent).

Kevin Kofler (./6436) :
Si tu as accès physique à la machine, tu peux emmener le disque carrément. Ou si tu ne veux pas laisser de traces, tu le démontes, tu le recopies avec un boîtier adaptateur USB pour disques SATA (ça coûte moins de 5€) et tu le remets en place.

Pas forcément. Tu peux avoir accès à un écran+clavier sans avoir accès à la machine (surtout un serveur), soit parce qu'il est dans une baie verrouillée, soit parce que le boîtier est verrouillé, soit parce qu'il s'agit d'une VM à laquelle tu accèdes depuis un hyperviseur (et il y a des hyperviseurs qui permettent de donner des droits restreints justement pour qu'un opérateur de supervision ne puisse pas accéder aux disques de la VM directement).

Kevin Kofler (./6436) :
Où veux-tu mettre ton keylogger si tout est crypté? Et si tu y arrives, alors il suffit aussi de démonter pour mettre ton keylogger.

Justement, tout n'est pas crypté là puisque tu accèdes à un shell non crypté. Et dans la plupart des installations destkop (pas serveur, du coup) où j'ai pu voir un cryptage des données, seul les home directories étaient cryptés, et ce de façon individuelle pour que chaque utilisateur ne puisse pas accéder aux répertoires des autres. Du coup, toute le système est en clair.

Ce problème concerne les setups ou /boot est en clair, qui ne sont pas secure.

si /boot est chiffré, c'est bon, sauf avec un keylogger dans l'UEFI, mais a priori faut signer les binaires UEFI sinon macache?

https://techcrunch.com/2016/11/16/microsoft-joins-the-linux-foundation/
Voila voila. Il gele en enfer.

oui, lol

Le truc bien avec le mon de de l'informatique, c'est que des surprises absolument impensables peuvent toujours arriver

Encore 2 ou 3 ans et ils vont annoncer que Windows 11 sera bâtit sur un noyau Linux.

Et wine par dessus.

Apple l'a bien fait, hein

Kevin Kofler (./6436) :
Si tu as accès physique à la machine, tu peux emmener le disque carrément. Ou si tu ne veux pas laisser de traces, tu le démontes, tu le recopies avec un boîtier adaptateur USB pour disques SATA (ça coûte moins de 5€) et tu le remets en place.

Bien sûr, et tu restes 2h sur place… Là, on parle d'une petite minute d'intervention.

Euh non, pas besoin de démarrer sur clé USB pour crypter /boot. La seule chose qui ne doit pas être cryptée est GRUB, vu que c'est lui qui demande le mot de passe. Et donc tu peux crypter /boot aussi, parce que GRUB est soit dans la partition système EFI (une partition /boot/efi séparée), soit pour le mode BIOS legacy, dans une partition dédiée (GRUB BIOS boot partition, sur GPT) ou dans le MBR (vieilles tables de partition MBR/DOS).

À partir du moment où tout n'est pas signé/chiffré, c'est mort quand il y a une faille de ce genre (si le boot est vérolé, tout le reste l'est aussi).

C'est débile de refuser un shell à quelqu'un qui a un accès physique à la machine, ça ne sert à rien niveau sécurité.

bah bien sûr que si… il faudrait vraiment que tu regardes comment fonctionne la sécurité en informatique. C'est bien plus crédible d'avoir un accès fugitif (on te laisse par erreur 2 min tout seul dans un bureau, par exemple) qu'un accès pendant 2 ou 3h (le temps de démonter la machine sans laisser de trace, copier le disque dur, tout remonter…).
Accessoirement, c'est beaucoup mieux de corrompre la machine de façon pérenne, vu que ça va te donner un point d'entrée sur le réseau et potentiellement plus tard pénétrer plus loin vers des serveurs intéressants, même s'il n'y a rien sur la machine corrompue.

Full


Ça les arrivé avec une clef USB chez un fournisseur qui voulait fournir des documents, en cherchant les dits fichiers jai trouve tout un tas de doc amusante comme lanschematique qu'ils refusaient de nous fournir...

OBO (./6441) :
https://techcrunch.com/2016/11/16/microsoft-joins-the-linux-foundation/Voila voila. Il gele en enfer.

WTF???

Le pire, c'est que la Linux Foundation est l'employeur de Linus Torvalds.