Cryptage disque physique sur debian/ubuntu

Cryptage disque physique sur debian/ubuntu - réseaux et sécurité - Linux et OS Alternatifs

Marsh Posté le 03-10-2012 à 13:28:32    

Bonjour,
 
Je cherche la possibilité de crypter un disque pour :
 

  • Que le disque sortie de la machine ne soit pas lisible, les données principalement (a voir si le disque complet peut etre illisible serait parfait)
  • Que le système puisse bouter tout seul et lancer les services automatiquement sans saisi de mot de pass ni login (comme un serveur classique)


Mais que si le serveur et/ou le disque si il est volé les données soit illisible sans le mot de pass du compte root ou autre, et que le disque sorti du serveur soit illisible aussi.
 
Il faudrait une solution qui soit assez performante si possible et surtout libre. C'est pour un site web + base de donnée (assez conséquente).
 
Si vous avez des idée ou orientation je suis preneur :)
 
Merci d'avance


---------------
Recette cookeo Recette de cuisine
Reply

Marsh Posté le 03-10-2012 à 13:28:32   

Reply

Marsh Posté le 04-10-2012 à 10:52:14    

http://korben.info/comment-chiffre [...] buntu.html
 
L'article date un peu mais ça doit correspondre à ton besoin il me semble


---------------
---------------
Reply

Marsh Posté le 04-10-2012 à 17:36:30    

Merci je vais regarder ça.


---------------
Recette cookeo Recette de cuisine
Reply

Marsh Posté le 04-10-2012 à 18:10:37    

Après avoir regarde ton lien.
 
Je vois que le plus sécure étant une cléf usb ou carte SD de boot qui si elle n'est pas présent au boot du serveur ne permet de rien faire.
 
Donc si vous avez un tuto sous la main pour cela avec une clefs de boot et une autre pour la passphrase direct dedans cela serait plus pratique.
 
Si vous avez des tutos pour ça je suis preneur.


---------------
Recette cookeo Recette de cuisine
Reply

Marsh Posté le 05-10-2012 à 11:57:05    

Bonjour,
 
 
En tous cas, pour ce que tu veux faire, cryptsetup / LUKS (qui utilise le device mapper / dm-crypt de Linux) est la solution libre de référence.
 
 
Dans les grandes lignes, pour faire simple on va dire, tu as 2 approches possibles :
1) sans LVM, de créer une partition unique pour le système et les données (le /) qui sera chiffrée
2) avec LVM, de créer un groupe de volumes chiffré contenant plusieurs volumes/partitions (système, données, et plus)
 
Dans le 1er cas, on se passe d'une couche supplémentaire qui est LVM, l'inconvénient étant l'usage d'une seule partition (pas de / et de /home séparé par exemple) à partir du moment où l'on ne souhaite avoir qu'une passphrase pour accéder au contenu chiffré (autrement il y aura une passphrase par partition chiffrée). Dans le second cas, on peut définir autant de partitions qu'on le souhaite (/, /tmp, /var, /home ...) avec une seule passphrase nécessaire (on applique le chiffrement au VG plutôt qu'aux LV), l'inconvénient étant que LVM est une couche supplémentaire s'intercalant entre le système de fichier et le device mapper (selon les cas, bien que ça soit transparent, cela peut occasionner un léger coût en I/O dépendant du disque, du layout utilisé et de l'algo de chiffrement employé).
 
Pour booter directement sans l'aide d'un périphérique externe (clé USB, carte SD, etc.) dans lequel serait stocké la passphrase LUKS, il faut disposer d'une partition /boot non chiffrée, de sorte à pouvoir charger les éléments nécessaires (noyau+modules, scripts et outils pour cryptsetup) à partir du ramdisk qui permettra ainsi d'accéder au contenu chiffré. L'usage d'un périphérique externe représente une sécurité supplémentaire contre de potentielles tentatives de hacking de /boot (modification/remplacement de l'initrd en vue de récupérer/détourner la passphrase utilisée).
 
Pour davantage de sécurité, que ce soit avec LVM ou sans, il est recommandé de chiffrer également la partition de swap (dans la mesure où des données sensibles peuvent y être transférées depuis la RAM). Si on n'a pas usage des fonctions de veille/hibernation, il est possible de recréer celle-ci à chaque boot avec une passphrase générée aléatoirement (autrement une passphrase persistente sera demandée).
 
Enfin, concernant le démarrage sans demande de la passphrase, c'est possible via authentification PAM et en particulier le module pam-mount (libpam-mount) si et seulement si le mot de passe root défini est identique à la passphrase.
 
 
Globalement, le contenu des données protégées par cryptsetup sera indéchiffrable sans la passphrase (y compris par des outils sophistiqués d'analyse/récupération de données sur disque), moyennant le fait que celle-ci doit avoir une certaine complexité (longeur, caractères alphanumériques + caractères spéciaux) et que la méthode de chiffrement choisie ne soit pas trop faible (celle par défaut, aes-cbc-essiv, sera largement suffisante dans la majorité des cas, mais rien n'empêche d'utiliser une autre méthode, par exemple twofish-xts-plain avec une clé SHA256 ou autre).
 
 
Les versions actuelles ou pas trop anciennes de Debian ou Ubuntu proposent dès l'installation des assistants pour la mise en place / configuration du chiffrement de contenu.
 
Quelques liens/tuto en vrac :
- page du projet cryptsetup / LUKS (us) : http://code.google.com/p/cryptsetup/
- la FAQ cryptsetup / LUKS (us) : http://code.google.com/p/cryptsetu [...] dQuestions (utilise pour bien cerner les concepts en crypto)
- howto Ubuntu pour chiffrer son disque (fr) : http://doc.ubuntu-fr.org/tutoriel/chiffrer_son_disque et sur cryptsetup (fr) : http://doc.ubuntu-fr.org/cryptsetup
- setup d'une Debian avec chiffrement (us) : http://madduck.net/docs/cryptdisk/
- wiki ArchLinux sur dm-crypt / LUKS (us) : https://wiki.archlinux.org/index.ph [...] _with_LUKS


---------------
THRAK (def.) : 1) A sudden and precise impact moving from intention, direction and commitment, in service of an aim. 2) 117 guitars almost striking the same chord simultaneously.
Reply

Marsh Posté le 05-10-2012 à 12:07:26    

Merci pour cette réponse très complète.
 
Le but pour moi d'après tes infos est de partir sur le modèle avec cléf usb de boot.
 
Avec ou sans la passphrase dedans (a voir) mais qui puisse être retiré après démarrage (genre un bip pour l'indiqué ou autre).
 
Le but étant de protéger l'accès au donnée contre un vol matériel.
 
Question puissance je pensais partir sur 2/4 go de ram (le prix est devenu ridicule). Mais un CPU avec instruction AES est mieux ? pour un serveur web avec base mysql (potentiellement lourde au bout d'un moment).
 
Tu conseille quoi comme cpu ? a savoir un user juste et le serveur apache/mysql qui tourne le reste quasi rien d'autre. Ceci sur un raid 1 (logiciel ou non je sais pas, déjà le logiciel possible avec un cryptage ? )
 
Des conseil sur la config nécessaire pour ne pas que cela soit un gouffre niveau puissance. SI tu as des indications je suis preneur.


---------------
Recette cookeo Recette de cuisine
Reply

Marsh Posté le 08-10-2012 à 22:35:09    

ionik a écrit :

Merci pour cette réponse très complète.


 :jap:  
 

ionik a écrit :

Le but pour moi d'après tes infos est de partir sur le modèle avec cléf usb de boot.
 
Avec ou sans la passphrase dedans (a voir) mais qui puisse être retiré après démarrage (genre un bip pour l'indiqué ou autre).
 
Le but étant de protéger l'accès au donnée contre un vol matériel.


La clé USB pour booter n'est pas forcément utile/pratique sur un serveur, notamment en cas de reboot à distance notamment, à voir donc.
 
Dans le cas d'un vol matériel, le boot à partir d'un périph externe n'est pas plus ou moins sûr. Ce qui compte surtout, c'est la qualité de la passphrase utilisée ; celle-ci étant indispensable pour accéder au contenu chiffré, le voleur ne pourra lire les données sur tes disques et à partir du moment où la passphrase est suffisamment complexe il est quasi-impossible (voire impossible) de la bruteforcer.
 
 

ionik a écrit :

Question puissance je pensais partir sur 2/4 go de ram (le prix est devenu ridicule). Mais un CPU avec instruction AES est mieux ? pour un serveur web avec base mysql (potentiellement lourde au bout d'un moment).
 
Tu conseille quoi comme cpu ? a savoir un user juste et le serveur apache/mysql qui tourne le reste quasi rien d'autre. Ceci sur un raid 1 (logiciel ou non je sais pas, déjà le logiciel possible avec un cryptage ? )
 
Des conseil sur la config nécessaire pour ne pas que cela soit un gouffre niveau puissance. SI tu as des indications je suis preneur.


Concernant la quantité de RAM, c'est un peu la réponse bateau : on en met autant qu'on peux. De nos jours, 4 Go commence à être un minimum pour un serveur LAMP standard (en fait, les technos web actuelles sont souvent mal optimisées gourmandes en termes de consommation de ressources, même pour un serveur à faible trafic -donc là, tout dépend de l'applicatif web que tu comptes faire tourner).
 
Du point de vue CPU, dans la mesure où tu comptes utiliser la crypto, c'est forcément mieux d'avoir le jeu d'instruction AES/AES-NI (à partir du moment où tu utilises cet algo, bien sûr) ; Linux dispose d'optimisations pour cela et les dernières versions du noyau disposent même de code optimisé qui en tire parti avec un gain supplémentaire en terme de performance pour les opérations de chiffrement/déchiffrement à la volée.
Autrement, question puissance, ça va dépendre essentiellement du type de requête web/MySQL à traiter ; pour faire sérieux, au moins un quadcore (type Xeon série E3 ou Intel Core i5 récent, avec AES-NI) ou mieux pour un serveur LAMP actuel. Tout dépend de ton budget.
Ne néglige pas non plus les I/O disques ; pour des accès en lecture/écriture de type db, sachant que les données vont être chiffrées, c'est un point à étudier (SATA 7200rpm à priori -mais si tu es riche, rien ne t'empêches de t'orienter vers du SAS 15000rpm).
 
Pour finir, il est tout à fait possible de faire du RAID (soft ou hard) avec de la crypto (me concernant je n'ai encore jamais essayé, mais on trouve sur le net des tuto sur ce sujet).


---------------
THRAK (def.) : 1) A sudden and precise impact moving from intention, direction and commitment, in service of an aim. 2) 117 guitars almost striking the same chord simultaneously.
Reply

Marsh Posté le 09-10-2012 à 00:09:55    

Merci pour ces infos encore

 

Pour la passphrase des conseil pour quelle soit indéchiffrable ?


---------------
Recette cookeo Recette de cuisine
Reply

Marsh Posté le 12-10-2012 à 12:14:28    

suffisament longue (~25 caractères) si composé de caractères simples.
 
ou >16 caractères si composée de caractères complexes
 
d'expérience il vaut mieux une passphrase longue et simple à rentrer, qu'une passphrase courte et obligeant les gesticulations hasardeuse avec le clavier avec des caractères complexes :o


---------------
noob :s
Reply

Marsh Posté le 12-10-2012 à 12:38:09    

Ok merci pour la prévision.


---------------
Recette cookeo Recette de cuisine
Reply

Marsh Posté le 12-10-2012 à 12:38:09   

Reply

Marsh Posté le 13-10-2012 à 12:07:54    

Bonjour,
 
La FAQ de cryptsetup/LUKS apporte des précisions intéressantes quant à la passphrase :

Citation :

PASSPHRASE CHARACTER SET: Some people have had difficulties with this when upgrading distributions. It is highly advisable to only use the 95 printable characters from the first 128 characters of the ASCII table, as they will always have the same binary representation. Other characters may have different encoding depending on system configuration and your passphrase will not work with a different encoding. A table of the standardized first 128 ASCII characters can, e.g. be found on http://en.wikipedia.org/wiki/ASCII


Citation :

5.8 Is LUKS secure with a low-entropy (bad) passphrase?  
 
Note: You should only use the 94 printable characters from 7 bit ASCII code to prevent your passphrase from failing when the character encoding changes, e.g. because of a system upgrade, see also the note at the very start of this FAQ under "WARNINGS".  
 
This needs a bit of theory. The quality of your passphrase is directly related to its entropy (information theoretic, not thermodynamic). The entropy says how many bits of "uncertainty" or "randomness" are in you passphrase. In other words, that is how difficult guessing the passphrase is.  
 
Example: A random English sentence has about 1 bit of entropy per character. A random lowercase (or uppercase) character has about 4.7 bit of entropy.  
 
Now, if n is the number of bits of entropy in your passphrase and t is the time it takes to process a passphrase in order to open the LUKS container, then an attacker has to spend at maximum

attack_time_max = 2^n * t


time for a successful attack and on average half that. There is no way getting around that relationship. However, there is one thing that does help, namely increasing t, the time it takes to use a passphrase, see next FAQ item.  
 
Still, if you want good security, a high-entropy passphrase is the only option. For example, a low-entropy passphrase can never be considered secure against a TLA-level (Three Letter Agency level, i.e. government-level) attacker, no matter what tricks are used in the key-derivation function. Use at least 64 bits for secret stuff. That is 64 characters of English text (but only if randomly chosen) or a combination of 12 truly random letters and digits.  
 
For passphrase generation, do not use lines from very well-known texts (religious texts, Harry potter, etc.) as they are to easy to guess. For example, the total Harry Potter has about 1'500'000 words (my estimation). Trying every 64 character sequence starting and ending at a word boundary would take only something like 20 days on a single CPU and is entirely feasible. To put that into perspective, using a number of Amazon EC2 High-CPU Extra Large instances (each gives about 8 real cores), this test costs currently about 50USD/EUR, but can be made to run arbitrarily fast.  
 
On the other hand, choosing 1.5 lines from, say, the Wheel of Time is in itself not more secure, but the book selection adds quite a bit of entropy. (Now that I have mentioned it here, don't use tWoT either!) If you add 2 or 3 typos or switch some words around, then this is good passphrase material.


---------------
THRAK (def.) : 1) A sudden and precise impact moving from intention, direction and commitment, in service of an aim. 2) 117 guitars almost striking the same chord simultaneously.
Reply

Marsh Posté le 04-04-2018 à 18:38:58    

bonjour  
je suis nouveau sur debian et je me demander si cétait possible de créer une clef usb pour démarrer sont pc  
(en gros) impossible de démarrer debian ou voir même sont pc sans la clef usb en question connecté? pour évité que des gens utilise mon pc s'en mon autorisation  
je suis en colocataire du coup je voudrais protégé mes comptes debian ect je ne trouve nul par un tuto ect  
je cherche sous clef usb de démarrage debian et rien  
merci pour votre aide

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed