Quelle stratégie de chiffrement choisir ?

Support Debian
#1

Bonjour,

Ce message dérive de ce premier message, afin d’en scinder les questions.

Rappel du contexte :
Il s’agit d’un mini serveur HP (plus d’infos ici) équipé de 4 baies sata (avec possibilités d’extensions sachant que j’ai à ma disposition 4x2To + 1x500Go + 1x250Go + 1x320Go (2’5) + 1x160Go (2’5)) et 4 Go de ram ecc, dont je voudrais me servir pour accueillir mes données (nas, sauvegardes) mais pas seulement (serveur d’impression, serveur vpn, dlna, etc).

Ce que j’aimerais :

  • un hébergement fiable de mes données
  • des sauvegardes fiables
  • une confidentialité de mes données (chiffrement, sachant que j’utilise déjà TrueCrypt qui, s’il n’est pas parfait, est le seul à ma connaissance à supporter le principe du double fond)

    Question :     Au vu de ces éléments, quelle stratégie de chiffrement choisir (efficace sans être trop contraignant/ralentissant, tout le système ou que les données, etc) ?

N’hésitez pas si vous avez besoin d’infos complémentaires, et d’avance merci pour votre aide ! :slight_smile:

#2

Re,

Aucun cryptage ni chiffrement pour moi. Ce qui m’empêchait de considérer que tout en une seule question était la meilleure solution :slightly_smiling:

#3

Bonjour,

perso j’utilise cryptSetup, je crée un conteneur sur le disque en fonction de mes besoin. Pas forcément besoin d’utiliser la taille complète du disque.

Ensuite, je ne crée le montage que quand j’ai besoin d’y accéder. Le conteneur est redimensionnable facilement.

#4

Bonjour,

Bon c’est à l’usage que l’on se rend compte de ce qui ne va pas : j’ai opté lors de l’installation pour le partionnement guidé LVM + chiffrement.

Ce qui fait qu’au démarrage du système, je dois rentrer ma passphrase, puis me loguer.
Or j’aimerais pouvoir lancer ma session, sans avoir besoin de rentrer de passphrase, idéalement pouvoir faire du WakeOnLan pour accéder à distance à mes données.

Dès lors, que me conseillez-vous comme chiffrement compatible avec cet objectif ?

#5

Je pense qu’on sera tous d’accord si je dis que du chiffrement de disque qui n’utilise pas un mot de passe n’a strictement aucun intérêt (si la machine est capable de déchiffrer le disque sans intervention humaine, tes données ne sont absolument pas protégées). Ça veut dire qu’on oublie direct le chiffrement complet du disque.

Malheureusement sans chiffrement complet du disque (et donc mot de passe au boot) la sécurité du système et la confidentialité des données sont fortement compromises :

  • le système lui-même est vulnérable puisqu’il est en clair sur le disque, il est très facile de booter en root et installer tous les malwares qu’on veut dont, par exemple, un keylogger pour récupérer les mots de passe permettant d’accéder aux parties chiffrées de ton système
  • tes données sont susceptibles d’être divulguées car tu ne pourras pas empêcher leur copie occasionnelle dans les dossiers temporaires comme /tmp ou bien sur le swap (rappelle-toi, tu ne veux pas de mot de passe au boot donc ces espaces temporaires sont en clair eux aussi), une simple lecture du disque révélera une partie de tes précieuses données

Si ces failles de sécurité te conviennent, tu as toujours des solutions sur trois pattes comme par exemple le chiffrement du /home qui peut être réalisé de plusieurs manières (peu importe la technique exacte, le principe c’est que lorsque ton utilisateur se connecte, PAM utilise son mot de passe pour monter et déchiffrer le répertoire de l’utilisateur) : encrypted.google.com/search?hl= … ypted+home
Tu peux aussi tout bêtement avoir une partition de données séparée du reste, que tu monteras manuellement une fois connecté à ton utilisateur.

Cela dit si ces failles de sécurité te conviennent alors le chiffrement ne sert pas à grand chose puisque, comme déjà expliqué, l’intégrité de ton système et la confidentialité de tes données ne sont pas assurées. Autant ne rien chiffrer plutôt que de faire les choses à moitié et avoir une fausse impression de sécurité.

#6

c’est notamment le /var/log qui doit être protégé aussi, sinon il existe une astuce pour les fichiers temporaires, leur montage se fait dans la RAM directement et aucune écriture sur le disque avec ces 2 lignes à rajouter dans le fstab, et s’ il ne se sert pas de la mise en veille prolongée, il peut désactiver le swap.

tmpfs /var/tmp tmpfs noatime 0 0
tmpfs /tmp tmpfs noatime 0 0

#7

Bonjour, et merci pour vos réponses à vous deux.

@syam :

Bien entendu nous sommes d’accord qu’une machine qui s’auto-déchiffre toute seule n’est pas sécurisée.
C’est pourquoi j’ai écarté par exemple l’idée d’un déchiffrement à l’aide d’un fichier-clé qui serait sur une clé usb branchée au serveur.

S’il y avait une solution pour rentrer la clé de déchiffrement à distance je la choisirais, mais de ta réponse je déduis que ce n’est malheureusement pas possible.

Il y a certes la solution d’utiliser une carte dédiée d’accès à distance, mais le prix me rebute, outre le fait que c’est une solution propriétaire.

Donc si je veux avoir accès à distance à mes données (sans devoir laisser mon serveur constamment allumé – et donc déchiffré, ce qui là aussi n’offrirait pas une très grande sécurité), je crois comprendre qu’il faut que je laisse le système en clair, quitte à chiffrer mon /home et mes autres partitions accessibles sur d’autres disques chiffrés.

Certes ça ne prémunit pas contre un boot clandestin pour installer des malwares sur la machine (tu dis que c’est facile mais ce n’est pas à la portée de tout le monde, pour ma part je ne sais pas faire), mais mon but est plutôt de me prémunir contre le vol matériel, ce serveur est chez moi, ne contient pas de secrets industriels, et je doute qu’un cambrioleur s’embarrasse de backdoorer le matériel qu’il convoite.
Dans ces conditions, un chiffrement du /home (voire du swap) ne me paraît pas inutile et permettrait d’accéder à distance à mon serveur, ou de lancer des tâches automatisées telles que des sauvegardes.

@nykoos :

Pour les fichiers temporaires effectivement je peux les monter en ram, cela étant je n’ai que 4 Go à voir si ça serait suffisant.
Qu’est-ce que contient /var/log qui puisse être sensible ?

#8

Tant que ta machine est allumée, l’éventuel attaquant n’a que deux manières d’accéder à tes données :

  • par le réseau (ça suppose une mauvaise configuration de ta machine ou des failles de sécurité)
  • en se connectant sur un utilisateur valide (faut trouver le mot de passe…)

Un cambrioleur (puisque c’est ça que tu crains) ne va s’amuser ni à l’un ni à l’autre : il va éteindre la machine et l’embarquer. Si tu chiffres le disque en entier, quand il la rallumera il sera coincé car il lui faudra le mot de passe pour déchiffrer le disque.
Reste la question des attaques via le réseau (qui n’ont rien à voir avec un éventuel cambrioleur) mais là ça dépend fortement des services que tu vas ouvrir sur l’extérieur…

#9

Oui, ou par cold book attack, pour rester dans les scénarii. :wink:

Tu reparles du chiffrement intégral, mais d’une part si j’ai bien compris ça ne me permet pas d’accéder à mon serveur à distance, et d’autre part sauf erreur le chiffrement du /home seul ne permettrait pas pour autant à un cambrioleur ayant embarqué la machine d’en déchiffrer le contenu, non ?
Après certains sont ravis de laisser leur machine en clair pour remettre la main sur le voleur :wink:

#10

Ce n’est pas l’accès à distance qui est le problème, mais le démarrage de la machine (car il nécessite un mot de passe lors du boot). Si ta machine reste allumée il n’y a aucun problème.

J’avoue, je n’ai pas cherché en détail comment fonctionne le montage/déchiffrement automatique du /home.
Étant donné que PAM se sert du mot de passe utilisateur pour déchiffrer le disque, il se passe quoi si l’attaquant boote la machine en single-user (init=/bin/bash pour contourner le login root) et change le mot de passe de l’utilisateur ? Si ça se trouve c’est pas un problème, mais c’est le genre de chose qu’il faut vérifier (et même tester) avant de faire reposer ta sécurité là-dessus.

#11

Salut,

As-tu seulement prévu que l’on ne boote pas par défaut sur le cd et que la possibilité de changer l’ordre de boot n’est pas validé (F8 ou F11). :slightly_smiling: