en virtualisation : les processus et les fichiers sont isolés les uns des autres. Le seul lien entre machines passe par le réseau (penser à configurer son garde-barrière)
Le seul lien entre les machines invitées.
Parce que l'hote à accès à tout.
Pour ce qui est continuité du service, un MAC* n'apportera rien du tout.
(* : oui je viens de me rendre compte que j'ai inversé MAC et DAC dans mon précédent message
DAC -> on peut les modifier.
Ca veut dire "Discretionnary Access Control"
MAC -> on ne peut pas
Ca veut dire "Mandatory Access Control"
)
--------------------------- POINT 1 --------------------------------------
1 - la confidentialité de certaines données
Donc point "1", quelques éclaircissement sur les MAC.
(je pense que la virtualisation tu as déjà une bonne idée).
sur les MAC, il y a deux approches, les approches par label, et les approches par pathname.
apparmor travaille sur les chemins de fichier, alors que selinux travaille sur les labels.
Ensuite je ne te cache pas qu'une MAC est pas forcément simple a configurer, mais normalement la plupart des services basiques ont déjà leur règles selinux, et que si le service ne fait rien de trop particulier, ça ne pose pas plus de problème que ça à configurer (comme disais eric gerbier, tu lance le "learning mode" (ou mode persmissif sous selinux)
tu as la liste des accès qui sont censés être refusés, et ensuite tu créé ta règle, après avoir vu ceux qui sont normal, et ceux qui sont inutiles (par exemple un certain nombre de soft essaient d'ouvrir /dev/urandom, mais en réalité n'en ont absolument pas besoin).
Le gros intérêt de selinux, c'est le mode MLS (assez mal supporté par les distribs, donc il faudra mettre la main à la pate), qui permet de faire de la hierarchie dans les droits (par exemple top secret > secret > confidential), avec des règles style bell lapadula
De base selinux (sans mls) permet aussi de faire de la catégorisation (MCS : multi catégory security).
Apparmor je ne connais pas donc je ne peux pas trop te dire, mais je pense que ça ne pose forcément trop de problème.
Ensuite , si on le veut avec selinux, même en étant admin de la machine, on peut bloquer la possibilité de changer les règles de sécurité et de voir les audits de sécu et les données (on peut lancer/arrêter les services etc..., mais pas interagire avec la sécurité selinux)
Bien entendu ces règles ne s'entendent pas avec un accès physique à la machine ;)
Bref, on peut faire des trucs très complet, mais peut être beaucoup overkill pour un truc perso.
Le problème de la virtualisation, c'est que c'est la même approche de la sécurité que le NAT, ça n'a pas été pensé pour.
Si j'ai un accès à une de tes machines, il faut que j'ai accès aux autres.
Donc il faut que tu blinde chacune de tes machines virtuelle, non seulement contre l'extérieur, mais aussi contre chacune de ses copines, parce que dès qu'une de ses copines est infectée elle va servir de relais d'attaque et de bastion.
Niveau temps et complexité sur la conf à faire en plus, je pense que la virtualisation est gagnante (moins couteux en temps, et plus "classique" ).
Niveau challenge, ben c'est inversement proportionnel ;)
------------------------------ POINT 2 ------------------------------------
2 - l'intégrité des données du serveur
Quel que soit la solution, comme disait goëdel (incomplétude toussa), on ne peut pas s'assurer que l'ensemble est bon si on reste au sein du même ensemble.
Il faut donc avoir fatalement une base, considéré comme "sur" (accès en lecture seule) indiquant une signature des données.
Il faut aussi que le logiciel/... qui effectue la vérification soit sur (sur ce même accès).
Une fois que ce postulat est complété, tu as plusieurs logiciels qui font ça, comme samhain ou tripwire, de tête.
Mais quel que soit la solution choisie, tu auras le même problème.
---------------------------------- POINT 3 ----------------------------------
3 - la continuité des services (à mon niveau bien sûr, pas à 100%)
Quel que soit la solution choisis, il faudra détecter la perte de service, et le relancer.
Sachant que la perte de service n'implique pas forcément la perte du système (par exemple, un système de virtualisation peut considérer que tout fonctionne bien même si le service applicatif ne tourne pas dans l'OS invité).
Par contre, le gros "plus" des VM "niveau OS" (et au dessus : noyau + os) , c'est que si tu te trompe dans la conf de la machine, tu as toujours la solution de repli d'attaquer l'host pour reconfigurer la vm.
Bon c'est un peu brouillon, donc je me delande si je ne t'ai pas plus embrouillé qu'autre chose ^^
[^] # Re: Virtualisation... Mais c'est quoi
Posté par briaeros007 . En réponse au message Quand utiliser la virtualisation. Évalué à 2.
Le seul lien entre les machines invitées.
Parce que l'hote à accès à tout.
Pour ce qui est continuité du service, un MAC* n'apportera rien du tout.
(* : oui je viens de me rendre compte que j'ai inversé MAC et DAC dans mon précédent message
DAC -> on peut les modifier.
Ca veut dire "Discretionnary Access Control"
MAC -> on ne peut pas
Ca veut dire "Mandatory Access Control"
)
--------------------------- POINT 1 --------------------------------------
1 - la confidentialité de certaines données
Donc point "1", quelques éclaircissement sur les MAC.
(je pense que la virtualisation tu as déjà une bonne idée).
sur les MAC, il y a deux approches, les approches par label, et les approches par pathname.
apparmor travaille sur les chemins de fichier, alors que selinux travaille sur les labels.
Ensuite je ne te cache pas qu'une MAC est pas forcément simple a configurer, mais normalement la plupart des services basiques ont déjà leur règles selinux, et que si le service ne fait rien de trop particulier, ça ne pose pas plus de problème que ça à configurer (comme disais eric gerbier, tu lance le "learning mode" (ou mode persmissif sous selinux)
tu as la liste des accès qui sont censés être refusés, et ensuite tu créé ta règle, après avoir vu ceux qui sont normal, et ceux qui sont inutiles (par exemple un certain nombre de soft essaient d'ouvrir /dev/urandom, mais en réalité n'en ont absolument pas besoin).
Le gros intérêt de selinux, c'est le mode MLS (assez mal supporté par les distribs, donc il faudra mettre la main à la pate), qui permet de faire de la hierarchie dans les droits (par exemple top secret > secret > confidential), avec des règles style bell lapadula
De base selinux (sans mls) permet aussi de faire de la catégorisation (MCS : multi catégory security).
Apparmor je ne connais pas donc je ne peux pas trop te dire, mais je pense que ça ne pose forcément trop de problème.
Ensuite , si on le veut avec selinux, même en étant admin de la machine, on peut bloquer la possibilité de changer les règles de sécurité et de voir les audits de sécu et les données (on peut lancer/arrêter les services etc..., mais pas interagire avec la sécurité selinux)
Bien entendu ces règles ne s'entendent pas avec un accès physique à la machine ;)
Bref, on peut faire des trucs très complet, mais peut être beaucoup overkill pour un truc perso.
Le problème de la virtualisation, c'est que c'est la même approche de la sécurité que le NAT, ça n'a pas été pensé pour.
Si j'ai un accès à une de tes machines, il faut que j'ai accès aux autres.
Donc il faut que tu blinde chacune de tes machines virtuelle, non seulement contre l'extérieur, mais aussi contre chacune de ses copines, parce que dès qu'une de ses copines est infectée elle va servir de relais d'attaque et de bastion.
Niveau temps et complexité sur la conf à faire en plus, je pense que la virtualisation est gagnante (moins couteux en temps, et plus "classique" ).
Niveau challenge, ben c'est inversement proportionnel ;)
------------------------------ POINT 2 ------------------------------------
2 - l'intégrité des données du serveur
Quel que soit la solution, comme disait goëdel (incomplétude toussa), on ne peut pas s'assurer que l'ensemble est bon si on reste au sein du même ensemble.
Il faut donc avoir fatalement une base, considéré comme "sur" (accès en lecture seule) indiquant une signature des données.
Il faut aussi que le logiciel/... qui effectue la vérification soit sur (sur ce même accès).
Une fois que ce postulat est complété, tu as plusieurs logiciels qui font ça, comme samhain ou tripwire, de tête.
Mais quel que soit la solution choisie, tu auras le même problème.
---------------------------------- POINT 3 ----------------------------------
3 - la continuité des services (à mon niveau bien sûr, pas à 100%)
Quel que soit la solution choisis, il faudra détecter la perte de service, et le relancer.
Sachant que la perte de service n'implique pas forcément la perte du système (par exemple, un système de virtualisation peut considérer que tout fonctionne bien même si le service applicatif ne tourne pas dans l'OS invité).
-----------------------------------------------------------------------------------------------
Par contre, le gros "plus" des VM "niveau OS" (et au dessus : noyau + os) , c'est que si tu te trompe dans la conf de la machine, tu as toujours la solution de repli d'attaquer l'host pour reconfigurer la vm.
Bon c'est un peu brouillon, donc je me delande si je ne t'ai pas plus embrouillé qu'autre chose ^^