Bonjour à tous,
(Si il y avait eu un forum sur l'admin sys je l'aurais mis dedans mais j'ai pas trouvé mieux que le forum général)
Je viens de m'acheter un petit serveur pour faire de l'auto-hébergement (web, mail et rsync). La virtualisation est à la mode et il est désormais courant d'avoir une machine virtuelle par service. Personnellement, je me méfie des modes. Certes la virtualisation ça fait pro, mais faire tourner plusieurs services sur un même serveur c'est possible depuis que les OS sont multitâche. Après, la virtualisation permet de consolider en isolant les applications, mais virtualiser tout un système juste pour une application, c'est un peu exagérer non ?
Alors... virtualisation ou pas ? J'espère que vous pourrez m'éclairer de vos conseils avisés.
Je débute en admin sys et je ne sais pas comment m'y prendre pour gérer la sécurité de mon serveur. J'avoue que j'ai un peu peur des hordes de bots qui vont prendre le contrôle de mon petit ordinateur. Quels sont les vrais risques de se faire pirater quand on fait juste tourner apache ou postfix.
Si vous avez des astuces, des liens intéressants, des bouquins à me conseiller...
Forum général.général Quand utiliser la virtualisation
9
fév.
2011
# Jails ?
Posté par Xavier Teyssier (site web personnel) . Évalué à 4.
Si tu veux un truc quand même un peu sécurisé, sans sortir l'artillerie lourde, tu peux regarder du côté des "Jails" (http://fr.wikipedia.org/wiki/BSD_Jail). Certes, c'est du BSD, mais tu n'as pas précisé quel OS tu utilises...
Il me semble qu'il y a l'équivalent sous Linux, mais je ne rappelle plus du nom. Vserver peut-être.
L'idée générale, c'est qu'au lieu d'avoir plusieurs machines virtuelles cloisonnés, tu as plusieurs images cloisonnées d'un même système.
[^] # Re: Jails ?
Posté par ulver . Évalué à 2.
http://wiki.openvz.org/Main_Page
http://fr.wikipedia.org/wiki/OpenVZ
Et depuis quelques versions, le kernel Linux embarque sa propre solution : LXC (OpenVZ et Vserver restent des patchs externes).
http://lxc.sourceforge.net/
[^] # Re: Jails ?
Posté par Old Geek . Évalué à 1.
je reste à openvz.
[^] # Re: Jails ?
Posté par Gmax . Évalué à 1.
Je n'ai encore jamais essayé BSD alors je ne vais peut-être pas faire mes premiers pas d'auto-hébergement avec, mais BSD est en haut de ma liste de trucs à découvrir.
LXC, ça a l'air très bien aussi. Simple et surtout parfaitement intégré à Linux.
J'ai trouvé un cas d'utilisation assez proche du mien => http://artisan.karma-lab.net/node/1749
Quelqu'un d'autre a testé ?
[^] # Re: Jails ?
Posté par kedare . Évalué à 0.
Faites gaffes avec OpenVZ par contre, au niveau de la gestion de RAM c'est très aléatoire selon ce que vous faites, certains environnements fonctionnent très mal, par exemple j'avais une application Java qui consommait maximum 512Mo de ram sur un serveur physique, la même lancé sous OpenVZ consommait plus de 2Go de ram pour la même chose. En gros une application lancé sous OpenVZ consomme toujours plus que la même chose sans virtualisation a cause d'un overhead. Selon les environnements utilisé ca peut être assez énorme comme dans mon cas...
[^] # Re: Jails ?
Posté par nullard3d . Évalué à 1.
Pour commencer plus doucement, il y a Proxmox qui mixe OpenVZ et KVM et qui vient avec une interface web : http://proxmox.com/products/proxmox-ve
L'avantage, c'est qu'on a une solution clef en main en 3 clics. Il peut télécharger lui-même des templates de différentes distributions (debian, centos, ...) et on accède indifférement aux VM et VZ via un plugin VNC-like.
Il y a un point noir, c'est que par défaut l'installeur requiert un proc 64bits + extension VT, même si on ne fait que de l'openVZ, et qu'il formate toute la machine :-(
Bref, à voir selon ton niveau/appétit technique :)
(note: un template est simplement un tar.gz d'une arborescence complète (faite par ex. avec debootstrap) et personnalisée. Pour créer un nouveau conteneur, il suffit de la dézipper en lui affectant un nom + IP. C'est un avantage par rapport à un système de vraies VM où on se tape en général l'installeur Linux ou Windows à chaque fois)
[^] # Re: Jails ?
Posté par daimrod . Évalué à 2.
# Pour la virtualisation.
Posté par xenom . Évalué à 1.
J'y vois un interet dans ton cas, c'est d'apprendre et de découvrir les VM, ou comme indiqué avant les jails BSD.
# pour tester des solutions avant d'investir
Posté par NeoX . Évalué à 2.
- pour tester un OS que tu ne connais pas sans casser ta machine
[^] # Re: pour tester des solutions avant d'investir
Posté par totof2000 . Évalué à 2.
# Parce qu'une seule distrib/OS n'a pas tous les avantages ?
Posté par weierstrass01 . Évalué à 1.
Alors oui on va me moinsser en disant que les backports, ça existe (c'est vrai !). Mais pour prendre mon cas, je maintiens un wiki (dokuwiki) dont les révisions (sécurité + fonctionnalités) évoluent très vite et que je bidouille beaucoup (intégration LDAP+https+custo fichiers PHP).
J'aurais pu utiliser les backports, mais une VM dans mon cas précis me permet de laisser une Debian SID (ou Arch, je ne me suis pas encore décidé) avec les nouveaux paquets intégrés en standard tout en sachant pertinemment que je peux tout casser : au pire je reclaquerai une image de backup.
Et puis quand on expose un serveur web avec du php bidouillé, c'est aussi intéressant que le processus soit isolé niveau sécurité.
Même si je rejoins les avis précédents : openVZ permettrait de le faire également.
Bien sûr, la découverte de KVM m'a beaucoup motivé à me tourner vers cette solution, que je pense plus versatile qu'openvz ou les hyperviseurs de niveau 2 (ceux qui ont besoin que le système installé ait un noyau modifié).
Je suis curieux de voir les autres réponses à ta question !
# Virtualisation... Mais c'est quoi
Posté par briaeros007 . Évalué à 10.
Il y a plusieurs niveau de virtualisation : pour faire simple
-> virtualisation "basique" du fs/process pour contenir une seule application -> chroot et jails
-> virtualisation de l'os, mais _pas_ du noyau -> vserver et openvz, ...
-> virtualisation du systeme (os + noyau), voir d'une machine
xen, vmware esx qemu, boschs, kvm
(avec grosso modo deux types de virtualisation
---> bare metal (type 1) où le noyau et toute la couche de virtualisation peut accéder au plus près du matos pour avoir le max de perf
---> "server" (type 2) ou la virtualisation est plus proche d'un logiciel qui tourne sur un os.
-> virtualisation "full matériel" (partition matériel, que l'on peut trouver sur des gros sun, des ibm, etc..)
Bien évidement le type 1 offre de bien meilleurs perfs que le type 2. La virtualisation matériel offre de meilleur perfs que la logiciel, et la virtualisation qui utilise un seul noyau (chroot, vserver, ...) offre de meilleures perfs qu'un hyperviseur.
Donc on a plusieurs choses, forte différente que l'on regroupe sous le même vocable.
Pour du chroot, voir carrément de tout l'os (vserver), oui attribuer un service par VM est une possibilité, car l'impact en perfs c'est surtout l'impact sur le disque, le noyau étant exactement le même partout.
Bien entendu, SPF oblige, si une attaque a lieu sur le noyau/hyperviseur/..., on peut réussir à sortir sur les autres environnements.
Donc quel est l'intérêt de la virtualisation ?
La plupart du temps c'est pour :
-> pouvoir gérer facilement les besoins d'un service.
-> pouvoir gérer la "séparation des pouvoirs" (sécurité,...)
-> disaster recovery (tu considère le service comme la vm, donc tu n'as pas à savoir si il faut aussi installer tel ou tel logiciel en même temps : tout est dispo tout de suite).
-> ...
Bref, des avantages non négligeable pour une entreprise, surtout en terme de gestion et d'approvisionnement.
C'est donc bien souvent de la virtualisation de l'ensemble du système.
chroot/jails/vserver/openvz/... c'est beaucoup plus accès pour
-> séparation des pouvoirs et la sécurité.
-> conf du système un peu différente (je pense surtout à openvz qui a des possibilitées de conf réseau beaucoup plus sympa que vserver)
(et un peu disaster recovery, vu que les infos sont hierarchisée et pas besoin de chercher dans 5000 répertoires différents).
Maintenant, ouverture pour partir sur autre chose
-> as t'on forcément besoin d'utiliser des chroots/jails pour faire de la sécurité ?
Bien sur que non,parce que dans tous les cas, on repose sur la sécurité du noyau. Donc si on fait confiance au noyau pour "enforcer" les droits avec un vserver, on peut lui faire confiance pour "enforcer" les droits avec une MAC/DAC.
Donc l'autre intérêt est d'offrir, de façon très simple une vision limitée du système à l'appli (pas besoin d'audit compliqué pour savoir que ce qui est en dehors du vserver, alors un process dans le vserver ne pourras pas le voir).
Mais, parce qu'il y a un mais, une autre possibilité existe : celle des DAC
Les MAC sont des droits que l'utilisateur peut modifier (par exemple avec chmod, setfacl)
les DAC sont des droits qui ont été définies une bonne fois pour toute, et qu'une fois mis en place, il n'est plus possible* de modifier.
C'est les système de sécurité type selinux ou autre.
Donc, avant de se poser la question "ais je besoin de la virtualisation" pose toi plutot la question "quel est mon besoin".
La virtualisation est un moyen, pas un but.
[^] # Re: Virtualisation... Mais c'est quoi
Posté par Gmax . Évalué à 1.
Effectivement, mes besoins sont d'assurer :
1 - la confidentialité de certaines données
2 - l'intégrité des données du serveur
3 - la continuité des services (à mon niveau bien sûr, pas à 100%)
Pour 1 j'ai pensé chiffrer les partitions de sauvegarde rsync.
Pour 3 j'ai pensé à un gestionnaire de configuration type puppet et une application de monitoring type Nagios (il faudrait que je trouve plus adapté à ma situation).
Pour 1, 2 et 3 la virtualisation ou l'isolation peuvent être aussi utiles en cloisonnant les données et les services (d'où ma question).
Je ne connais pas très bien les MAC, DAC, apparmor et compagnie, mais c'est peut être ce qu'il me faut.
Quelle différence en terme de sécurité par rapport à l'isolation / la virtualisation ?
[^] # Re: Virtualisation... Mais c'est quoi
Posté par eric gerbier (site web personnel) . Évalué à 2.
avec apparmor et compagnie : il faut préciser pour chaque processus, les droits d'accès aux fichiers. Apparmor offre un mode apprentissage qui facilite le travail, mais d'expérience, c'est lourd à maintenir.
[^] # Re: Virtualisation... Mais c'est quoi
Posté par briaeros007 . É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 ^^
[^] # Re: Virtualisation... Mais c'est quoi
Posté par Gmax . Évalué à 2.
J'aime bien l'idée de faire de la sécurité avec quelque chose qui est fait pour ça, et je pense que c'est plus intéressant à apprendre.
J'ai déjà vu tourner tripwire lors d'un stage mais je n'avais pas pensé à l'utiliser. Le souvenir que j'ai c'est qu'il y a beaucoup (trop) d'alertes inutiles (notamment à cause des màj). Je pense qu'il doit falloir apprendre à l'utiliser.
Puppet et CfEngine sont fait a priori pour surveiller les services et les relancer si besoin mais je ne sais pas comment ils se maintiennent eux mêmes en service.
[^] # Re: Virtualisation... Mais c'est quoi
Posté par briaeros007 . Évalué à 2.
Ensuite si tu n'as pas trop envie de te prendre la tête, tu peux toujours utiliser "debchecksum" sous debian, qui va checker les md5 des binaires avec le md5 stocké dans le paquet (il faut donc que /var/lib, de tête, et les binaires de debchecksum soient sur).
pour puppet et cfengine, jamais utilisé. Mais cfengine pour moi est plus un repo/validation de conf, qu'un outil de monitoring.et de relance.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.