cryptage serveur - Page 1

Salut les gens
Je dois crypter les données d'un serveur Linux qui sera probablement virtualisé (linux hébergé sur un Windows).
Normalement seul l'admin pourra se loguer sur le serveur linux, mais sur la machine Windows, c'est potentiellement moins bien contrôlé (au minimum l'admin local pourra se loguer sur le windows, car il s'agira d'un serveur envoyé à l'étranger)

N'y connaissant pas grand chose en cryptage et sécurité, je me demande un peu vers quoi m'orienter...
Est-ce que le mdp du compte linux est récupérable (surtout si on copie le disque virtuel, puisque le serveur sera virtualisé) ? J'ai souvenir que oui... On avait fait ça dans un TP #triNoobOui#

Bien sûr, les données à sécuriser doivent être disponibles tout le temps pour l'application qui tourne sur le serveur, donc il me semble que le cryptage via truecrypt (ou équivalent) est peu efficace, non ? (=le "pirate" réinitialise le mdp du compte linux, et a du coup accès à tout puisque le disque truecrypt est déjà monté, non ?)

Enfin bref, c'est pas très clair pour moi... Merci d'avance pour votre aide

Pour la partie compte Linux : Oui, c'est pas compliqué de changer le mot de passe, il suffit de monter la partition et de modifier le fichier /etc/passwd et hop, t'es le maitre de la machine.
Pour le reste, je ne sais pas trop, par cryptage, tu entends quoi exactement ?

/etc/shadow

mais oui c'est le principe.

Pen^2 (./1) :
Bien sûr, les données à sécuriser doivent être disponibles tout le temps pour l'application qui tourne sur le serveur, donc il me semble que le cryptage via truecrypt (ou équivalent) est peu efficace, non ? (=le "pirate" réinitialise le mdp du compte linux, et a du coup accès à tout puisque le disque truecrypt est déjà monté, non ?)

Je ne vois pas trop où est ton problème... sous Linux, quelle que soit ta conformation, l'utilisateur root aura toujours accès à tout lorsque c'est monté.

La solution pour éviter qu'on te change le mot de passe root facilement est de rendre inaccessible le système à froid (donc pas d'accès à celui-ci sans les bons droits).
La solution est de crypter tout le disque système avec TrueCrypt (mais attention : si le serveur redémarre, il faudra une intervention humaine pour saisir le mot de passe en étant physiquement présent au moment du boot - sur certains serveurs, il y a possibilité d'avoir un accès distant dès le démarrage du BIOS, mais ça n'est pas dispo en standard chez tous les constructeurs).
Sachant que tu peux en plus cascader les cryptages, ça n'est pas tellement gourmand en utilisation processeur (avoir un cryptage du disque système et des autres partitions + un cryptage des /homes [si tu es dans le cas d'un serveur de fichiers ; ça n'est pas valable pour un serveur applicatif] par dessus avec --encrypt-home en paramètre lors de la création de l'utilisateur).

Bon, je ne suis pas non plus spécialiste, et c'est un peu du bricolage, je ne sais pas quelle est la sécurité avérée du système (et il y a 2/3 bricoles à savoir quand on crypte une partition système, en particulier qu'au moment du boot, lorsque le mot de passe est demandé, on n'est plus en AZERTY et que le clavier est géré bizarrement : de ce que j'ai vu, c'est la matrice clavier qui est prise en compte [donc si tu as créé un volume avec un chiffre 5 depuis le pavé numérique, tu ne peux pas utiliser le chiffre 5 du haut du clavier alphabétique et inversement]... enfin, il faut faire des tests avant de passer en prod, quoi...).

Intéressant de crypter le système, merci... Pour le reboot, ça ne serait pas un problème vu que le système serait virtualisé (accès distant à l'hôte)

matmook (./2) :
Pour le reste, je ne sais pas trop, par cryptage, tu entends quoi exactement ?

ben, que personne ne puisse lire les données, quoi

Nil (./4) :
Je ne vois pas trop où est ton problème... sous Linux, quelle que soit ta conformation, l'utilisateur root aura toujours accès à tout lorsque c'est monté.

Oué c'est bien ça le problème ; cela dit, si on est obligé d'arrêter le système pour réinitialiser le mdp root, ça démontera le volume truecrypt, donc ça pourrait être suffisant, non ?

Oui, exactement. Après, je n'ai crypté avec TC que des systèmes Windows, et ça semble être une limite http://www.truecrypt.org/docs/?s=sys-encryption-supported-os

donc selon vous je devrais pouvoir partir sur une solution truecrypt des données, sans trop me soucier du reste ?

Oui, sauf que là tu vas avoir un problème : tu ne peux pas crypter un système Linux, ça n'est pas supporté par TC. Donc deux solutions :
- Tu crées un disque virtuel dans lequel tu mets ton volume (non crypté) qui sert pour ta VM (GROS inconvénient : une fois qu'il est monté sur le serveur, n'importe qui peut avoir accès au volume décrypté, donc forcer un mdp root vide en accédant au fs).
- Trouver une solution similaire à TC ou une distrib qui permet le cryptage du système façon TC.

Oué mais finalement c'est pas vraiment utile de crypter le système, si ?
Tout ce que je veux, c'est protéger une arborescence particulière. Si je place toutes les données de l'arborescence dans un volume truecrypt, le "pirate" ne pourra éventuellement se loguer qu'après avoir rebooté, et aura donc perdu le montage du volume truecrypt sensible, non ?

Ah oui, oui, à ce moment là il faut que le montage de l'arborescence soit en mode interactif et que le mot de passe n'apparaisse dans aucun script. Comme ça, même si le root change son mot de passe, il ne pourra pas lire les données. Par contre, il pourra supprimer le conteneur crypté.

Nil (./11) :
il faut que le montage de l'arborescence soit en mode interactif et que le mot de passe n'apparaisse dans aucun script.

oué bien sûr

Nil (./11) :
Comme ça, même si le root change son mot de passe, il ne pourra pas lire les données.

On est bien d'accord que ce n'est pas possible de changer le mdp à chaud ? Il faut obligatoirement monter la partition système dans un autre système et écraser passwd ?

Par contre, il pourra supprimer le conteneur crypté.

aucune importance


merci

Pen^2 (./12) :
On est bien d'accord que ce n'est pas possible de changer le mdp à chaud ? Il faut obligatoirement monter la partition système dans un autre système et écraser passwd ?

Oui. Après, il y a peut-être des méthodes de sioux que je ne connais pas (monter une partition déjà active, par exemple, c'est normalement impossible, mais qui sait) et des failles système... et tout sudoer peut-être considéré comme root potentiel même s'il n'a pas le droit de lancer un shell root.

Je n'ai pas tout suivi, mais si j'ai bien compris tu veux héberger un système virtualisé sécurisé dans un environnement hôte qui ne l'est pas ?

Pour moi ce n'est pas vraiment faisable (exemple : même si ton disque virtuel est super bien crypté, ce qui est en RAM ne le sera pas, et récupérer le contenu de la RAM d'une VM est trivial quand tu as accès au système hôte).

Pen^2 > Debian 6 propose de chiffrer intégralement le disque dur lors de l'installation (mais ce n'est pas avec TC).
Astuce : prends un mot de passe indépendant du clavier azerty ou qwerty

Ceci dit, même sur une machine physique, tant que la chaîne n'est pas intégralement signée et le disque chiffré, tu ne peux rien garantir... (c'est tout l'intérêt du Secure Boot, par exemple).
Mais bon, chiffrer le disque dur est un bon début.

Zerosquare (./14) :
Pour moi ce n'est pas vraiment faisable (exemple : même si ton disque virtuel est super bien crypté, ce qui est en RAM ne le sera pas, et récupérer le contenu de la RAM d'une VM est trivial quand tu as accès au système hôte).

Ouais, comme le dit Flan, si la chaîne intégrale n'est pas cryptée, il peut avoir des problèmes - il y a des serveurs qui proposent une RAM cryptée pour éviter une écoute électronique, mais à partir du moment où une personne se connecte à la machine, elle travaille forcément dans un espace décrypté, donc peut théoriquement lire tout et n'importe quoi à la moindre faille de la gestion mémoire de l'OS. Cela dit, à part couler son serveur dans du béton, le débrancher, et le plonger dans la fosse des Mariannes, il y a toujours un risque.

Ben l'une des règles de base de la sécurité, c'est que si l'accès physique est possible, c'est cuit. Or pour un serveur virtualisé, accès physique = accès à l'hôte, même de manière non physique. Du coup c'est tout aussi risqué que de mettre un serveur physique dans une salle de colocation si tu ne fais pas confiance au propriétaire...

Zerosquare (./17) :
Or pour un serveur virtualisé, accès physique = accès à l'hôte, même de manière non physique.

Il doit bien y avoir des solutions de virtualisation qui cryptent les échanges avec la RAM pour éviter que les autres serveurs ne puissent comprendre ce qu'il y a dans la RAM de l'un en cas de famille, non ?

Je ne sais pas, mais ça m'étonnerait, ça aurait un impact monstrueux sur les perfs.

Nil (./16) :

Zerosquare (./14) :
Pour moi ce n'est pas vraiment faisable (exemple : même si ton disque virtuel est super bien crypté, ce qui est en RAM ne le sera pas, et récupérer le contenu de la RAM d'une VM est trivial quand tu as accès au système hôte).

Ouais, comme le dit Flan, si la chaîne intégrale n'est pas cryptée, il peut avoir des problèmes - il y a des serveurs qui proposent une RAM cryptée pour éviter une écoute électronique, mais à partir du moment où une personne se connecte à la machine, elle travaille forcément dans un espace décrypté, donc peut théoriquement lire tout et n'importe quoi à la moindre faille de la gestion mémoire de l'OS. Cela dit, à part couler son serveur dans du béton, le débrancher, et le plonger dans la fosse des Mariannes, il y a toujours un risque.

Je n'ai pas dit que la chaîne intégrale devait être chiffrée, j'ai dit qu'elle devait être signée
Tout n'a pas besoin d'être chiffré, genre le boot loader par exemple...

Zerosquare (./19) :
Je ne sais pas, mais ça m'étonnerait, ça aurait un impact monstrueux sur les perfs.

Bof... Je travaille régulièrement sur des volumes cryptés (cryptage maximal truecrypt) montés dans un système crytpé (idem) et les performances sont quasi similaires à sans cryptage... après, ça dépend de l'usage de ram de la machine virtuelle, mais bien souvent on est surpris par le peu de ressources demandées par beaucoup de services - là où d'autres sont hyper gourmands, mais ne peuvent se satisfaire d'un modèle comme une mv).

Indice: débit RAM >>>> débit disque (surtout que les accès disques sont limités, alors que la RAM sert en permanence)

Oui, mais le temps d'accès au disque <<< temps d'accès à la ram donc ça dépend vraiment de l'usage qui est fait

Ben justement, le facteur limitant c'est avant tout le débit du disque, pas le cryptage, c'est pour ça que ça ne pourrit pas trop les perfs.

La RAM est infiniment plus rapide (on dépasse maintenant les 10 Go/s) et il y a des accès vraiment tout le temps, que ce soit pour charger le code, ou lire ou écrire des buffers.

lvm & autre outils pour le raid a la base ne permettent pas de crypter une partition "systeme" sous linux?

Nil (./13) :
Oui. Après, il y a peut-être des méthodes de sioux que je ne connais pas (monter une partition déjà active, par exemple, c'est normalement impossible, mais qui sait) et des failles système...

oué oué, bien sûr, mais ce qui compte pour mon cas, c'est de protéger contre un gars qui voudrait faire une copie du disque sur une clé usb, quoi

Nil (./13) :
et tout sudoer peut-être considéré comme root potentiel même s'il n'a pas le droit de lancer un shell root.

à priori, je ne pense pas que personne aurait un compte sur le serveur linux virtualisé en dehors de l'administrateur. Donc, pas de sudo !

Zerosquare (./14) :
Je n'ai pas tout suivi, mais si j'ai bien compris tu veux héberger un système virtualisé sécurisé dans un environnement hôte qui ne l'est pas ?

Oué, voilà. En gros, l'admin local (confiance limitée mais quand même acceptable) met à disposition la machine physique, et on installe dessus ce qu'on veut. En l'occurrence, une machine Linux virtualisée auquel sur laquelle le gars n'aura pas de compte.

Zerosquare (./14) :
Pour moi ce n'est pas vraiment faisable (exemple : même si ton disque virtuel est super bien crypté, ce qui est en RAM ne le sera pas, et récupérer le contenu de la RAM d'une VM est trivial quand tu as accès au système hôte).

Trivial pour qui ? En gros, le but est d'empêcher un employé d'emporter les données chez un concurrent.

flanker (./15) :
Pen^2 > Debian 6 propose de chiffrer intégralement le disque dur lors de l'installation (mais ce n'est pas avec TC).

Mmm, j'ai vu ça avec mon install linux, au moment de créer la partition. N'ayant pas vu d'option, j'ai hésité. C'est un minimum robuste ?

flanker (./15) :
Ceci dit, même sur une machine physique, tant que la chaîne n'est pas intégralement signée et le disque chiffré, tu ne peux rien garantir... (c'est tout l'intérêt du Secure Boot, par exemple).

Oué enfin là, le but est d'empêcher le gars de copier la base de données et les exécutables.

flanker (./15) :
Mais bon, chiffrer le disque dur est un bon début.

Zerosquare (./17) :
Ben l'une des règles de base de la sécurité, c'est que si l'accès physique est possible, c'est cuit.

Oué je sais bien...

Disons qu'avec un chiffrement intégral du disque dur, tu as une bonne protection contre un gars moyennement motivé.

Le LVM de Debian permet de l'AES-256, donc c'est largement suffisant (et si tu as un processeur récent, il y une accélération matérielle pour l'AES).

C'est du Red Hat. C'est bon aussi ? (CentOS pour être précis)

Je suis en train d'en installer un pour tester.

La solution de cryptage officielle pour Fedora et RHEL/CentOS est LUKS. Sinon, il y a aussi tcplay (logiciel libre compatible TrueCrypt) dans EPEL (le dépôt de paquetages pour RHEL/CentOS géré par le projet Fedora) pour RHEL/CentOS 6.

Pen^2 (./26) :
Trivial pour qui ? En gros, le but est d'empêcher un employé d'emporter les données chez un concurrent.

Bon, disons qu'avec un disque dur virtuel chiffré, il pourra pas se contenter d'une simple copie. Après, s'il veut vraiment vous piquer vos données, je pense qu'il y arrivera. Je ne sais pas s'il existe des utilitaires pour récupérer les mots de passe depuis la RAM d'une VM, mais il y a de fortes chances que quelqu'un y ait déjà pensé.