Forum général.général Quand utiliser la virtualisation

Posté par .
Tags :
6
9
fév.
2011
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...
  • # Jails ?

    Posté par (page perso) . Évalué à 4.

    Une machine virtuelle par service peut se défendre dans certains cas. Pour de l'autohébergement, ça me semble un peu violent.
    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 . Évalué à 2.

      Tu as OpenVZ sous Linux qui est très bien :

      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 (page perso) . Évalué à 1.

        j'ai du faire un retour arrière sur lxc, trop jeune pour l'instant,
        je reste à openvz.
        • [^] # Re: Jails ?

          Posté par . Évalué à 1.

          J'avais déjà entendu parler de Jails et OpenVZ. Ça va être l'occasion de regarder ça de plus près. J'ai trouvé un article ici => http://www.unixgarden.com/index.php/administration-systeme/c(...) (pas encore lu).

          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 . É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 . Évalué à 1.

        Je recommande OpenVZ aussi. On peut configurer chaque conteneur ou "VZ" aux petits oignons (quota disque évidemment, mais aussi différents quota sur chaque type de mémoire, nb de process, nb de fichiers ouverts, ...), mais ça demande un certain investissement en temps, notamment si on fait soi-même ses templates.

        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 . Évalué à 2.

      Et avec Debian et le noyau BSD (Debian/kFreeBSD) il y a aussi les jails non ? C'est sans doute pas encore super au point, mais dans un futur assez proche cela devrait l'être.
  • # Pour la virtualisation.

    Posté par . Évalué à 1.

    Une machine virtuelle par service c'est, à mon avis, inutile pour de l'auto hébergement. Ça peut être utile pour de gros services, pour eviter qu'un problème (surcharge, compromission,...) entraine l'arrêt de tous les autres services.

    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 . Évalué à 2.

    - pour simuler un ensemble de machine avant de lancer un investissement.
    - pour tester un OS que tu ne connais pas sans casser ta machine
    • [^] # Re: pour tester des solutions avant d'investir

      Posté par . Évalué à 2.

      Ca peut se justifier pour des machines ayant des services devant tourner sur des versions d'OS un tant soit peu différents, ou pour éviter d'impacter certains services lorsqu'une machine a besoin de rebooter pour mise à jour noyau par exemple (dans le cas ou un logiciel donné évolue souvent et nécessite des versions de noyau ou lib système récente à chaque upgrade). Ca peut servir aussi, quand on a peu de moyen, à avoir un environnement de tests et un environnement de prod sur le même serveur physique. Pour de l'auto hébergement ça ne serait pas si stupide : un environnement de "prod" qui lui évolue peu, et une environnement de "dev+tests" qui lui bouge tout le temps.
  • # Parce qu'une seule distrib/OS n'a pas tous les avantages ?

    Posté par . Évalué à 1.

    Je me suis posé exactement la même question, à savoir "à quoi la virtualisation pourrait bien servir pour un serveur@home ?", et ce qui m'a décidé à me remonter un autre serveur avec le matériel kivabien (support AMD-VT) c'est tout simplement que ma Debian Lenny est certes inaltérable, mais pourvu de paquets datant un peu (pléonasme).

    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 . Évalué à 10.

    Parler de virtualisation c'est bien beau, mais de quoi parles t'on ?
    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 . Évalué à 1.

      Merci pour toutes ces précisions et pour la mise au point finale.

      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 (page perso) . Évalué à 2.

        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)

        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 . Évalué à 2.

          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 . Évalué à 2.

            C'est pas si compliqué finalement le principe des MAC. La mise en œuvre après je ne sais pas...

            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 . Évalué à 2.

              en même temps les updates sont faites par toi, donc quand tu as un message qui dis "coucou il y a eu tout ça qui a changé" le même jour que ton update, tu sais d'où ça vient ;)

              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 à ceux qui les ont postés. Nous n'en sommes pas responsables.