Catégorie : Libre

Les différents types de virtualisation : Classification

Antoine 5 commentaires

tech-presentation-2Après avoir vu l’intérêt de la virtualisation, je vais pouvoir vous présenter les différents types de virtualisation qui existent aujourd’hui sur le marché. Ces billets sur la virtualisation reprennent le contenu de l’AC (avec Romain Hinfray) et de la TX (avec Julie Facon). Je ferais des retours vers ces deux projets en synthétisant le contenu car ca fait trop long pour un blog.

Vous avez surement entendu parler de très nombreux types de virtualisation avec un panel de noms au moins aussi nombreux. Au début, on a tendance à rapidement s’y perdre. Je vais donc essayer dans cet article proposer une classification de la virtualisation qui est celle que nous avons proposé lors de l’AC.

On virtualise quoi ?

Tout d’abord, il est essentiel de se poser la question « Qu’est ce qu’on virtualise ? ». Il est possible de virtualiser beaucoup de choses de nos jours. Un début de liste comporterait des routeurs, des switchs, des applications, des systèmes d’exploitation, de l’espace disque et ainsi de suite. La virtualisation de routeurs et de switchs se fait notamment par les VRF dans les IOS Cisco ou bien des applications telles que Nexus de Cisco (switchs virtuels pour VMWare).

La virtualisation d’application est également un secteur important du marché même si il est peu connu car il n’existe pas, à ma connaissance, d’application libre sur ce secteur. Pour vous illustrer le principe, avec la virtualisation d’application vous pouvez vous connecter sur un portail, cliquer sur l’application de votre choix et elle s’exécute en quelques secondes sans être installé sur votre poste. Je ne sais pas comment ca fonctionne mais c’est assez impressionnant à voir. Un exemple d’implémentation de cette technologie est Citrix XenApp (pas grand chose à voir avec Xen a priori).

Ce dont je vais essentiellement parler, c’est la virtualisation de système d’exploitation. C’est le type de virtualisation généralement le plus connu. Le but de ce type de virtualisation est d’exécuter simultanément plusieurs systèmes d’exploitation sur une même machine physique. Les exemples d’implémentation ne manquent pas : Xen, VMWare, KVM, Hyper-V, …

On virtualise comment ?

Nous allons nous intéresser plus particulièrement à la virtualisation de systèmes d’exploitation. Je vous propose tout d’abord un arbre qui résume bien les différents types de virtualisation. Une fois de plus, il s’agit d’une proposition de classification, il en existe surement plein d’autres.

Classification

Comme on le voit dans le schéma, la première distinction qui est faite est la distinction entre virtualisation de systèmes d’exploitation et virtualisation de processus. Il y a une différence fondamentale entre exécuter un système d’exploitation complet et effectuer un cloisonnement de processus. Des exemples de virtualisation de processus sont OpenVZ, les jails BSD ou encore les zones Solaris.

Dans la virtualisation de systèmes, nous avons distingué à nouveau deux catégories : les systèmes modifiés et les systèmes non modifiées. Cette distinction est également essentielle car elle va régir tout le fonctionnement de la virtualisation. Dans le cas de systèmes modifiées, le système d’exploitation va avoir « conscience » d’être présent au dessus d’une couche de virtualisation et va travailler efficacement avec cette dernière. Dans le cas de systèmes non modifiés, la couche de virtualisation va faire tout son possible pour faire croire au système d’exploitation qu’il est présent sur du matériel physique.

Dans la catégorie des systèmes modifiés, on va retrouver la paravirtualisation. La paravirtualisation est le type de virtualisation inventé par le projet Xen. Ce type de virtualisation a été rendu possible grâce aux logiciels libres car il a été possible de modifier et d’adapter le noyau Linux ou BSD ou Solaris. Microsoft a mis en pratique cette méthode avec son produit Hyper-V intégré à Windows Server 2008.

Dans la catégorie des systèmes non modifiées, on va retrouver la virtualisation totale et la virtualisation matérielle assistée. Cette dernière n’est qu’une amélioration de la virtualisation totale grâce aux extensions processeurs AMD-V et Intel VT.  Ce type de virtualisation est le type de virtualisation le plus utilisé grâce à la simplicité de fonctionnement des applications et à la puissance des outils d’administration existants. On retrouve dans cette catégorie VMWare, VirtualBox et Virtual PC entre autres.

Pour conclure et mettre une nuance à cette classification, il est possible de mélanger les types de virtualisation, je m’explique. Il est possible, par exemple, dans un système d’exploitation fonctionnant en virtualisation matérielle assistée de rajouter des pilotes de paravirtualisation afin d’améliorer les performances ou d’ajouter une fonctionnalité.

L’intérêt de la virtualisation

Antoine 9 commentaires

tech-presentation-2Je vous ai déjà présenté le projet Xen dans un billet précédent en vous en ventant ses mérites mais je ne vous ai même pas présenté l’intérêt de la virtualisation. Je vais donc faire le tour des avantages que peut apporter la virtualisation à une plateforme informatique existante ou bien à un projet de plateforme informatique. Ces avantages se divisent en quatre catégories principales : coût, sécurité, criticité et performances.

Constat

Dans une architecture classique (sans virtualisation donc), chaque service dispose de sa propre machine physique. Cette règle informelle ou plutôt « Best Practice » permet d’éviter que la compromission d’un service impacte d’autres services sur la machine. En conséquence, une architecture de ce type implémente une machine par service proposé sans compter les « Hot Spare ». Les « Hot Spare » sont des machines qui attendent une panne de la machine principale pour de prendre le relai et assurer la continuité du service.

Au final, les machines sont peu utilisées surtout avec les configurations matérielles d’aujourd’hui comprenant processeurs Dual-Core ou Quad-Core.

Avantages en terme de coût

La virtualisation va permettre de mutualiser les équipements physiques afin de supporter plusieurs systèmes d’exploitation sur une même machine physique. Au lieu d’avoir une machine physique pour chaque service, nous allons donc avoir un système d’exploitation pour chaque service. Les deux situations ne sont pas totalement équivalentes mais on s’en approche.

Une société va donc pouvoir héberger dans un espace moindre, avec une climatisation moindre et avec une consommation électrique moindre un même nombre de services. La variable d’ajustement sera le taux d’utilisation des machines physiques. L’architecture sera donc utilisée de manière plus efficace. De manière plus concrète, au lieu d’avoir un parc de serveurs bas de gamme hébergeant chacun un service, une société va pouvoir acheter un nombre restreint de serveurs haut de gamme plus puissants. Ceci va lui permettre de louer moins d’espace en datacentre et d’utiliser proportionnellement moins d’électricité.

Il faut cependant noter qu’une architecture virtualisée rajoute une surcharge de maintenance dans la mesure où il a été rajouté une couche applicative entre les ressources physique et le système d’exploitation. Cette couche applicative aura besoin d’être maintenue ce qui générera des coûts supplémentaires par rapport à une architecture classique.

Avantages en terme de sécurité

Etant donné que la virtualisation exécute plusieurs systèmes d’exploitation sur une même machine, il est primordiale qu’elle assure un cloisonnement parfait. Une faille dans ce dernier constituerait une faille de sécurité considérable. La virtualisation s’efforce d’arriver à un cloisonnement proche du cloisonnement physique. Le cloisonnement dans le cadre de la virtualisation reste cependant largement meilleur que dans le cas de plusieurs services sur un même système d’exploitation.

La virtualisation donne également la possibilité de créer des environnements de tests standardisés afin d’effectuer des tests de pénétration ou bien d’infection. La possibilité de mettre en pause une machine virtuelle est intéressante afin de pouvoir étudier le comportement de code malicieux par exemple. Je ne connais pas d’implémentation de cette possibilité mais la perspective me semble prometteuse.

Avantages en terme de criticité

Nous avons qualifié la possibilité d’exécuter plusieurs systèmes d’exploitation sur une même machine physique en tant qu’avantage. Il s’agit certes d’un avantage en terme de coût mais surement pas d’un avantage en terme de criticité. Une panne matérielle induit l’indisponibilité d’un grand nombre de services. La virtualisation permet de palier à cette problématique en fournissant de nombreux outils.

Dans le cadre d’un système d’exploitation classique, il est simple de sauvegarder des applications, des données ou des fichiers de configuration. Cependant, la virtualisation va permettre de faire une sauvegarde de la totalité des données d’une machine. Dans le cas d’une restauration de sauvegarde, il sera possible de restaurer un système d’exploitation fonctionnel rapidement sans devoir tout réinstaller. Ceci est un gros avantage de la virtualisation.

La virtualisation permet également de migrer des systèmes d’exploitation d’une machine physique à une autre en moins d’une seconde. Ceci permet d’éviter une indisponibilité en cas de modification de la configuration matérielle d’un équipement.

Avantages en terme de performance

Dans le cadre d’une architecture classique, si une machine nécessite plus de mémoire vive par exemple, il est nécessaire de prévoir un temps d’indisponibilité et le déplacement d’un technicien sur site. La virtualisation va permettre d’augmenter les ressources physiques de manière instantanée et sans manipulation de matériel ni déplacement de personnel. Il suffit d’exécuter une commande afin de rajouter de la mémoire vive ou de l’espace disque. Traditionnellement, ces augmentations se faisaient dans la mesure des ressources physiques. Depuis quelques temps, il est possible d’attribuer plus de mémoire vive qu’il est disponible dans la machine. La mémoire vive non utilisée par une machine virtuelle sera ainsi attribuée à une autre.

Sécuriser un serveur Apache avec PHP : suPHP

Antoine 3 commentaires

suphp_logoCe billet fait suite aux précédents billets sur le sujet de la sécurisation d’Apache avec PHP à savoir la problématique et un premier élément de réponse. Pour résumer rapidement, nous avons vu les problèmes que posait une installation par défaut d’Apache supportant le PHP dans le cas d’un serveur web mutualisé tel qu’on pourrait le trouver chez un hébergeur. Nous avons ensuite vu comment la configuration PHP pouvait influer sur la sécurité de l’installation.  Dans ce billet, nous allons voir la configuration et l’utilisation de suPHP.

Objectif

J’avais parlé de la problématique des droits avec lesquels s’exécutent les scripts PHP ainsi que du fait qu’il n’y ait qu’un seul fichier de configuration PHP pour tous les sites présents sur une même machine. Le module Apache dénommé suPHP va permettre de répondre à ces deux problématiques et de rajouter même quelques fonctionnalités supplémentaires. Si on va sur leur site, on se rend bien compte que l’objectif de suPHP est d’exécuter les scripts PHP avec les droits du propriétaire du script. Ceci va nous permettre d’attribuer un utilisateur par site et donc d’obtenir un meilleur cloisonnement. Nous verrons par la suite plus en détail la configuration et les possibilités offertes par suPHP.

Installation de suPHP

Sur une distribution de type Debian, l’installation se fait via le gestionnaire de paquet traditionnel apt-get.

# apt-get install libapache2-mod-suphp

# a2enmod suphp

Sur les autres distributions, vous pourrez soit passer par le gestionnaire de paquet soit par la compilation à la main. Comme pour tous les modules Apache, la compilation à la main est très simple et efficace. Il ne faut juste pas oublier de déclarer le module dans le fichier de configuration d’Apache.

Configuration de suPHP

Une fois que vous avez installé suPHP, vous n’avez finalement pas rajouté beaucoup de sécurité dans votre installation. Il va falloir s’atteler à la configuration. La première étape de la configuration est de s’assurer que chaque site ait son propre utilisateur. Sans cette mesure, suPHP est largement moins efficace. On va ensuite étudier le fichier de configuration de suPHP qui se trouve dans /etc/suphp/suphp.conf.

;Path all scripts have to be in
docroot=/data/www

Cette directive vous permet de configurer le répertoire dans lequel suPHP aura le droit d’exécuter des scripts PHP. Les scripts en dehors de ce répertoire ne seront pas exécutés et le serveur web affichera une erreur 500 (Internal Server Error).

; Security options
allow_file_group_writeable=false
allow_file_others_writeable=false
allow_directory_group_writeable=false
allow_directory_others_writeable=false

Ce jeu de directives va vous permettre d’autoriser ou non vos utilisateurs à mettre des droits très élargis à leur fichiers. Par exemple, si vous activez la première directive, suPHP refusera d’exécuter les scripts PHP qui permettent l’écriture par le groupe du propriétaire du fichier. A vous de voir si vous voulez implémenter ce type de restrictions. Je ne trouve pas ca très utile si vous avez bien réglé la directive PHP open_basedir.

; Minimum UID
min_uid=100
; Minimum GID
min_gid=100

Ce jeu de directives vous permet de paramétrer l’UID et le GID minimal avec lequel peuvent être exécutés des scripts PHP.  Ceci va vous permettre d’éviter que des scripts soient exécutés avec l’utilisateur www-data voire root. Il existe d’autres lignes de configuration que je n’ai pas explicitées ici. Je vous invite à consulter la documentation pour en savoir plus.

Configuration du VirtualHost

Une fois que nous avons correctement configuré suPHP, il n’est toujours pas actif. Il va falloir l’activer au cas par cas en fonction du VirtualHost. Ceci permet d’avoir une meilleur finesse de réglage quant à l’activation de ce module. Rien de plus simple pour l’activer il suffit de rajouter la ligne suivante dans le VirtualHost.

suPHP_Engine On

On va pouvoir ensuite rajouter plusieurs réglages fournis par suPHP afin d’implémenter plus de sécurité et de flexibilité. Comme je vous en avais parlé précédemment, il va être possible d’attribuer un fichier php.ini par VirtualHost. Il est essentiel que vos clients ne puissent pas modifier ce php.ini directement. Si cela est possible, il sera possible à n’importe qui de modifier la directive open_basedir supprimant ainsi un niveau de sécurité. On va donc rajouter la directive suivante :

 suPHP_ConfigPath /data/www/********.com/priv/php.ini

Au final, à travers ces trois billets nous avons pu faire un tour d’horizon permettant la sécurisation d’un serveur Apache doté de PHP. Je pense que l’implémentation des fonctionnalités présentées à travers ces trois billets permet d’atteindre un niveau de sécurité correct sur un serveur web mutualisé. Il n’existe bien sûr par de sécurité parfaite. Il faut surtout adopter une hygiène de configuration et de paramétrage en association avec la configuration correcte des modules associés.

Sécuriser SSH, c’est pas bien compliqué

Antoine 6 commentaires

doc_openssh_logo_2Vous le savez peut être déjà, une faille semble avoir été trouvé dans SSH. Pour ceux qui n’ont jamais fait d’administration système, le protocole SSH est le protocole utilisé pour administrer les serveurs Linux/BSD ainsi que de très nombreux équipements réseau. Qui dit faille SSH dit accès total aux machines disposant de ce service. Pour vous rassurer, la faille semble ne toucher que les versions les plus vieilles d’OpenSSH. Vous qui disposez d’une Debian, vous êtes à l’aise car vous savez que Debian a un cycle de release assez rapide. Vous qui croyiez être à l’aise sur votre RHEL (Red Hat Entreprise Linux) ou CentOS et la stabilité qu’un cycle de release lent, vous devez être plus stressé et vous avez bien raison ! Cependant, elle semble peu crédible et basée sur de très nombreuses hallucinations suppositions.

Constat

Tout le monde le sait, le SSH est probablement le protocole le plus sensible sur une machine ou un équipement voire sur Internet. Il semble cependant régner un climat de confiance excessive autour de ce protocole. Dans le même temps, d’autres protocoles sont ultra surveillés comme c’est le cas pour HTTP ou DNS alors qu’ils sont moins sensibles. Je pense que dire que SSH est le protocole le plus sensible n’est pas une exagération trop importante. Certes le protocole DNS est ultra critique, mais une faille sur le protocole SSH permettra la modification des zones DNS présentes sur la machine. Une faille SSH permettra de prendre la main sur les routeurs et de modifier les informations BGP et ainsi de suite.

Bloquer les accès

La plus simple des parades à toutes les failles éventuelles sur SSH est de bloquer l’accès à ce dernier. Bien sur, si vous bloquez l’accès complètement, vous ne pourrez plus administrer vos machines mais il y a tout de même des solutions. Il est indispensable de ne pas autoriser la terre entière à accéder à votre serveur SSH. On ne peut pas considérer le service SSH sécurisé si il est accessible par la terre entière. Vous pouvez mettre une règle de filtrage permettant de n’autoriser que l’IP de votre connexion Internet. Si vous avez une connexion avec IP dynamique, vous pouvez utiliser OpenVPN pour accéder à votre zone de serveurs et n’autorisez la connexion qu’à partir du serveur VPN. Si vous êtes une société avec un minimum de moyens, mettez en place un tunnel MPLS jusqu’à votre datacentre.

L’accès en root, c’est mal…

Il est également peu raisonnable d’autoriser les accès SSH directement en root. Si vous donnez le mot de passe root à tous les utilisateurs de la machine, il sera plus difficile de leur en interdire l’accès par la suite. Ceci est d’autant plus grave si votre serveur SSH est accessible par tout le monde. De plus, un accès avec un compte utilisateur permet d’éviter que tout le monde puisse faire rm -Rf / par erreur. Une exception existe à cette règle, si votre filtrage au niveau du réseau est suffisament efficace et que vous avez la possibilité de supprimer l’accès en supprimant l’accès au VPN, il est possible d’accéder directement en root aux serveurs.

Les livres pour comprendre Xen 2

Antoine

Voici le second opus des livres permettrant de mieux comprendre Xen. Alors que le premier livre était un plutôt un guide d’installation et de configuration de Xen, ce livre a pour but d’être une présentation en profondeur de Xen permettant un compréhension approfondie de son fonctionnement.

The Definitive Guide to the Xen Hypervisor

DefinitiveGuideXenHyp

Ce livre a pour objectif d’être la bible des développeurs de Xen et de former les futurs développeurs. Cependant, ce livre peut être abordé à plusieurs niveaux : un niveau développeur et un niveau administration système. C’est le deuxième niveau que m’avait conduit à m’intéresser à ce livre.

Ce livre contentera les développeurs dans la mesure où il part d’un point de vue global pour aller jusqu’à une analyse très approfondie du fonctionnement de Xen avec des exemples de fonctions en C et l’explication de leur fonctionnement.  N’étant pas développeur et n’ayant que très peu de compétences en programmation, il m’est assez difficile de commenter ce niveau de compréhension.

Ce livre contentera également les administrateurs système. La totalité de son contenu n’est pas forcément accessible à ces derniers surtout s’ils n’ont pas fait beaucoup de programmation auparavant. Cependant, une grande partie l’est tout de même. Un effort de compréhension conséquent est nécessaire pour réussir à assimilier les connaissances correctement. Une fois cet effort de compréhension effectué, le niveau de connaissance du lecteur sera largement supérieur à une personne qui a lu le livre précédent. Ceci donnera à la personne les connaissances permettant de résoudre bon nombres de problématiques liés à Xen qui dépassent la simple erreur de configuration.

Ce livre est cependant complémentaire au précédent. La lecture de ce livre ne suffit pas pour obtenir la configuration d’un serveur Xen et des domaines associés. Pour bien connaitre Xen, la lecture de ces deux livres est donc fortement intéressante. Ce livre peut servir de « suite » permettant d’approfondir au premier livre qui permet de faire une première mise en place.

Sécuriser un serveur Apache avec PHP : début de solution

Antoine 3 commentaires

apache_logoCe billet fait suite au précédent qui avait pour objectif de vous faire une démonstration des problématiques liées au déploiement d’un serveur web mutualisé basé sur Apache. Je vais donc vous présenter des solutions permettant de résoudre ces problèmes.

Limites

Je n’ai pas la prétention de vous permettre de sécuriser parfaitement un serveur Apache. Je vous présente ici une série d’éléments que j’ai pu apprendre à travers mon précédent emploi. Il faut dire qu’un hack de serveur web toutes les deux semaines, ca force à s’occuper de la sécurité des serveurs web. J’exagère, hélas, à peine.

Ces solutions de sécurisation permettent d’éviter qu’un site puisse nuire aux autres sites sur le serveur web. Si un site mal codé dispose de failles de sécurité rendant possible une attaque sur lui même, je n’ai pas de solution coté serveur à vous proposer. Dans ce cas, il faut se plonger dans le code et réparer les failles de sécurité. Ces solutions permettront tout de même de vous prémunir d’une attaque sur toute votre plateforme et de pouvoir rejeter la faute sur vos clients.

Choix du logiciel PHP

Tout d’abord, lorsque vous installez un serveur web, il est fortement recommandé d’installer la version Suhosin. Il s’agit d’une version de PHP qui a été patchée pour réparer des failles de sécurités connues. La liste des améliorations est disponible sur leur site. Si vous avez fait le choix judicieux de prendre une distribution Debian, les versions de PHP qui sont livrées avec disposent d’office du patch Suhosin. Je ne sais pas ce qu’il est des autres distributions mais je doute que ce soit le cas partout.

Ensuite, il faut avoir une version PHP à jour. Ca parait peut être inutile de dire ca mais ca reste une condition essentielle. La mise à jour des logiciels permet de bénéficier de la réactivité des communautés en termes de mises à jour de sécurité. Ce serait quand même dommage de ne pas en profiter et de se faire compromettre un serveur à cause de failles connues depuis plusieurs mois.

Configuration de PHP

La configuration de PHP peut largement influer sur la sécurité du serveur web. Il existe de nombreuses fonctionnalités de PHP qui permettent de faire des choses intéressantes pour le développeur mais très inquiétant pour l’administrateur système.

Tout d’abord, la directive fopen est une directive qui devrait être désactivée par défaut. Cette directive permet d’ouvrir un fichier et ensuite de le modifier ou bien de le lire. Par défaut, si cette directive est activée, il est possible de lire n’importe quel fichier dont /etc/passwd. « Mais /etc/passwd, tout le monde ne peut pas le lire ! ». Et bien si, les droits sur les fichiers /etc/passwd sont de 644. Le monde entier pourra donc trouver la liste des comptes utilisateurs de votre machine sur le web.

Ensuite, si un de vos clients a besoin de la directive fopen, car elle peut quand même être utile. Vous allez donc devoir restreindre l’accès aux fichiers ce qui est possible dans PHP via la directive open_basedir. Grace à cette directive, vous allez donc contraindre vos clients à ne pas sortir de leur répertoire que ce soit pour l’exécution de scripts PHP ou la modification/lecture de fichiers.. Il est également généralement recommandé de désactiver la directive register_globals mais je ne suis pas capable de justifier pourquoi. Je sais juste qu’il s’agit d’une option qui n’est plus d’actualité dans les versions de PHP d’aujourd’hui (Plus d’informations sur ce site).

Grace à ces éléments, la sécurité de votre serveur web sera déjà bien améliorée. Afin de pouvoir aller encore plus loin et améliorer le niveau de sécurité, je vous présenterais suPHP la prochaine fois.