Étiquette : Virtualisation

Architectures de virtualisation

Antoine 2 commentaires

Mardi dernier avait lieu la « soirée informatique » de l’Utt Net Group au foyer de l’UTT. L’objectif de cette soirée était de discuter d’informatique tous ensemble et d’apprendre des expériences des autres. Il s’agit d’un barcamp avec plusieurs modifications. Dans notre cas, la durée des présentations n’était pas limitée à priori, nous avons donné la possibilité à chaque orateur de choisir son temps de présentation dans la mesure du raisonnable.

Les présentations se sont déroulées les unes après les autres avec une pause barbecue car il faut bien alimenter notre cerveau. Cette soirée a été une réussite car elle a atteint son objectif de réunir des gens autour d’une passion commune. Seuls quelques petits « bugs » logistiques sont à retenir mais rien de bien grave.

En ce qui me concerne, j’ai effectué une présentation intitulée « Architectures de virtualisation ». L’objectif était de partir de la virtualisation et de faire le tour des autres éléments qui sont affectés par cette dernière. Les éléments étant affectés par la virtualisation retenus sont le stockage et le réseau. La présentation a duré 45 minutes.

Pour ceux que ca intéresse, mes slides sont disponibles en PDF et via le slideshare ci-dessous.

Architectures de virtualisation

Accélérer son site web avec Squid – 2

Antoine 2 commentaires

Dans le billet précédent, nous avons vu l’intérêt d’un reverse-proxy Squid ainsi que son installation et sa configuration basique. Dans ce billet, nous allons réellement utiliser les possibilités de Squid.

Rappels

Historiquement, les proxy HTTP ont été mis en place afin d’accélérer les chargements des pages web. A une certaine époque l’acronyme WWW pouvait avoir pour signification « World Wide Wait ». La solution apportée à ce problème a été de mettre en cache les contenus au plus proche de l’utilisateur par le biais de proxy.

La gestion du cache HTTP doit être géré du coté du fournisseur de contenu, à savoir le serveur web. En théorie, ce dernier a autorité sur les données du site qui pourront être mises en cache ou non. Ces informations sont transmises dans les en-têtes HTTP par le biais de divers champs que nous ne détaillerons pas tous ici. Un champ particulièrement intéressant est la durée de rétention dans le cache.

Par défaut, Apache n’envoie pas d’informations quant à la mise en cache du contenu ce qui signifie donc qu’en théorie les données de notre site ne seront pas mises en cache. Dans notre situation, cela signifie que Squid ne met rien en cache tant que nous n’avons pas configuré Apache pour lui indiquer qu’il est possible de le faire.

Configuration d’Apache

Nous allons donc devoir paramétrer Apache pour utiliser les en-têtes contrôlant la mise en cache de nos pages web. Ainsi, notre serveur Squid pourra prendre une partie de la charge de notre serveur web et ainsi le soulager.

Le module Apache qui nous intéresse plus particulièrement est mod_expires. Son activation est simple et, dans le cas de Debian, il est packagé avec Apache. Il suffit donc de l’activer comme suit.

# a2enmod expires

# /etc/init.d/apache2 restart

Une fois ce module activé, nous allons pouvoir le configurer.

Configuration de mod _expires

Nous allons pouvoir configurer mod_expires par le biais de fichiers .htaccess comme il est possible de le faire pour bon nombre d’autres modules. Ce module nous permet de gérer assez finement la mise en cache des fichiers. La syntaxe est simpliste mais efficace. Si vous souhaitez obtenir une explication exhaustive dans la syntaxe et de ses fonctionnalités, je vous recommande de consulter la documentation.

Pour ce site, j’ai choisi la politique suivante de mise en cache.

ExpiresActive On
ExpiresByType image/gif « access plus 1 week »
ExpiresByType image/jpeg « access plus 1 week »
ExpiresByType image/png « access plus 1 week »
ExpiresByType text/css « access plus 1 days »
ExpiresByType application/x-shockwave-flash « access plus 1 hour »

Ensuite, c’est à vous de voir ce que vous voulez que Squid mette en cache ou pas en fonction des fonctionnalités de votre site.

Vérification

Afin de vérifier si tout fonctionne correctement, je vous invite à consulter les log d’accès à votre serveur Squid. Des lignes comportant « TCP_HIT » s’afficheront lorsque Squid servira des données du cache à la place d’Apache. Si vous n’avez que des « TCP_MISS », il doit probablement manquer un élément à votre configuration.

Au final, cette méthode permet d’accélérer significativement son site web et ainsi d’améliorer son référencement sur Google. Dans mon cas, le temps de chargement de ce site a été divisé par un facteur 2 à 3 ce qui est tout de même très intéressant. Des lecteurs m’ont fait remarquer qu’il existait une alternative plus moderne à Squid, Varnish qui permettrait de définir des politiques de mise en cache plus fine. Je vous laisse donc y jeter un coup d’œil !

Accélérer son site web avec Squid – 1

Antoine 17 commentaires

La rapidité de l’Internet est une préoccupation omniprésente car elle améliore significativement l’expérience utilisateur. De plus, récemment Google a annoncé que la rapidité d’affichage des sites serait prise en compte dans le calcul de l’affichage des pages de résultat de recherche. Cette prise en compte avait de quoi en motiver plus d’un à accélérer l’affichage de son site, dont moi.

Contexte

L’affichage de ce blog était relativement lent. Il pouvait mettre plus de 5 secondes pour s’afficher complètement ce qui n’est pas un temps d’affichage très bon. J’ai donc entrepris de trouver une solution à ce problème.

Ce site est hébergé sur une machine virtuelle Xen dont le système d’exploitation est OpenSolaris 2009.06. Elle est globalement assez lente car relativement peu de mémoire lui est alloué. De plus, la cohabitation d’Apache et de MySQL sur le même système ne favorise clairement pas les choses. Certains médisants diront que WordPress et/ou PHP sont des facteurs de lenteur. Ils auront raison mais je n’ai aucune intention d’utiliser autre chose que WordPress car c’est un réel plaisir à l’utiliser.

Un peu de théorie

Un proxy ou en Français « serveur mandataire » est un serveur qui se place entre le client et le serveur. Le client va interroger le proxy qui va à son tour interroger le serveur. Le serveur répondra au proxy qui, à son tour, répondra au client. Ceci est le fonctionnement le plus classique mais on peut placer un proxy dans nombreuses configurations et donner au proxy une intelligence supplémentaire.

Dans le cas de proxys HTTP(S) classiques, on y ajoute des mécanismes de cache afin d’économiser de la bande passante. On peut également y ajouter des fonctions de filtrage d’URL afin d’éviter la consultation de certains sites.

L’exemple d’application du proxy qui nous intéresse ici est le reverse proxy. Le client n’aura aucune connaissance de la présence d’un proxy et pensera qu’il s’agit d’un serveur HTTP comme un autre. Le proxy interrogera ensuite le serveur web et la requête sera renvoyée au client. Dans cette situation, la fonctionnalité de cache du proxy est très intéressante car elle permet d’éviter le traitement de certaines requêtes au serveur HTTP. On pourrait également utiliser le proxy couplé à plusieurs serveurs HTTP afin d’effectuer du load balancing et de la redondance.

Une autre VM

La première étape a été de trouver une machine supplémentaire afin de ne pas faire cohabiter la pile LAMP et Squid sur le même serveur. Dans l’absolu, ce n’est pas impossible mais lorsqu’on a un serveur déjà surchargé, ce n’est peut être pas la meilleure idée.

Étant donné qu’OVH vient de lancer son offre miniCloud, ce projet était une parfaite excuse pour la tester. Le prix de cette offre est vraiment très bas. Pour une VM de 256Mo de RAM, cela revient à 8,5€/mois. J’ai donc crédité 10€ sur mon compte. L’interface de gestion n’est pas la plus esthétique ni la plus rapide mais elle fait l’affaire.

En une petite dizaine de minutes, j’avais donc à ma disposition une machine virtuelle Debian Lenny 64-bits. Le réel inconvénient de l’offre d’OVH est que l’IP de la machine virtuelle change à chaque fois que vous l’arrêtez par le biais de l’interface de gestion.

L’installation de la pile LAMP est très simple et je ne la détaillerai donc pas ici. Il existe des masses incroyables de documentation à ce sujet.

Squid

L’installation de Squid est très simple. Je l’ai installé sur OpenSolaris à partir des dépôts Blastwave via pkgutil. Dans le cas de Debian, un apt-get s’occupera de tout ca pour vous.

Une fois installé, nous pouvons passer à sa configuration. La configuration du reverse proxy est la suivante :

http_port 80 accel defaultsite=www.antoinebenkemoun.fr
visible_hostname vm.antoine.fr
cache_peer 178.32.yy.xx parent 80 0 no-query originserver name=myAccel
acl all src 0.0.0.0/0.0.0.0
cache_peer_access myAccel allow all
acl our_sites dstdomain antoinebenkemoun.fr www.antoinebenkemoun.fr antoinebenkemoun.com www.antoinebenkemoun.com
http_access allow our_sites

Tout d’abord, on indique à Squid d’écouter les requêtes sur le port 80 et que le site que l’on va proxy-er est « www.antoinebenkemoun.fr ». Ensuite, on lui indique l’IP du serveur web où est réellement hébergé le site. Il est ensuite nécessaire de définir un certain nombre d’ACL qui sont ici assez génériques et tout à fait simples. Dans l’exemple, nous avons autorisé le reverse proxy pour 4 sites et nous avons autorisé toutes les IP à visionner le site.

Il est également possible d’utiliser d’autres options afin de mieux régler votre reverse proxy. L’ajout d’un « access log » va vous permettre de voir les pages qui sont consultés mais surtout si le contenu est envoyé par Squid ou par votre serveur LAMP. Il est également possible de régler la quantité de mémoire vive utilisé pour le cache de pages web. L’espace mémoire utilisé pour le cache sera donc alloué en plus de l’espace mémoire du programme principal.

cache_mem 20 MB
cache_access_log /opt/csw/var/logs/access.log

Le chemin pour l’access log est adapté à mon OpenSolaris mais à vous de l’adapter à votre distribution. Si vous êtes sur Linux, vous voudrez surement placer les logs quelque part dans /var/log/.

Au final, nous avons installé notre serveur Squid et l’avons configuré en mode reverse-proxy. Dans le billant suivant, nous verrons les modifications qu’il faut apporter à notre serveur Apache afin d’utiliser réellement la fonctionnalité de cache du reverse proxy.

La sécurité de la virtualisation : suite et fin

Antoine 5 commentaires

Cet article complète le précédent sur le sujet de la sécurité de la virtualisation en abordant l’aspect réseau de stockage et essaye de présenter les risques réels de sécurité des plateformes de virtualisation. Il s’agira également du dernier billet sur ce sujet bien que je compte revenir sur ce sujet par la suite.

La sécurisation du stockage

La virtualisation n’ajoute pas de risque particulier à partir du moment où l’on suppose que l’attaquant dispose d’un accès physique aux données. Ce type d’exploit est donc uniquement inhérent au stockage sur disque.

Les réseaux de stockage en Fibrechannel n’ajoutent également pas de risque particulier. Seul les hyperviseurs ont accès aux supports de stockage distribués par le réseau de stockage. De plus, il est possible de gérer finement les accès aux différents supports de disque par les biais des techniques de « zoning ». Le zoning est une technique équivalente aux « Private VLAN » de Cisco dans le cas des réseaux Ethernet.

Contrairement à ce qui a été présenté Samedi dernier, la connexion des équipements Fibrechannel au réseau Ethernet n’ouvre pas de faille supplémentaire. Il n’est pas possible d’utiliser cette interface pour accéder aux données transitant sur le réseau de stockage. L’interface Ethernet permet uniquement d’accéder aux informations de configuration du commutateur.

Supposons qu’il soit possible d’accéder aux données transitant sur le réseau Fibrechannel par le biais de cette interface Ethernet. Toute tentative de spoofing d’adresse MAC serait parfaitement inutile car les réseaux Fibrechannel n’utilisent pas d’adresses MAC mais des WWN qui n’ont rien à voir. Les protocoles de communication sont différents et ne sont pas compatibles.

Cette problématique est cependant intéressante dans le cas des réseaux iSCSI qui n’ont même pas été mentionnés. Il n’est absolument pas souhaitable que les LAN iSCSI soient routables vers d’autres réseaux. Il est même recommandé d’avoir des équipements uniquement dédiés aux fonctionnalités iSCSI dans la mesure du possible.

Récapitulons…

Les potentielles interfaces d’attaque vers les hyperviseurs sont très peu nombreuses. Dans le cas de la virtualisation totale et de la virtualisation matérielle assistée, ces interfaces sont même inexistantes. Dans le cas des interfaces de paravirtualisation, leur utilisation est standardisée par le biais d’API mais la découverte de failles reste envisageable bien qu’aucune n’ait été trouvée à ce jour.

Les mécanismes de DoS sont régulés voire supprimés par les mécanismes classiques d’ordonnancement présents dans toutes les solutions de virtualisation.

Quels sont les risques ?

Les risques réels de sécurité inhérents aux plateformes de virtualisation se situent, d’une part, au niveau des interface de gestion. Les interfaces de gestion ne sont pas propres à la virtualisation mais leur utilisation dans ce cas particulier est généralisé.

L’accès aux interfaces de gestion doivent être sécurisés par les mécanismes réseau traditionnels ainsi que par le biais de méthodes d’authentification. Dans le cas d’une compromission de ces interfaces, les données et l’accès aux machines virtuelles reste indemne. Les interfaces ne disposent généralement pas d’accès particulier aux données, elles disposent uniquement d’une vue globale permettant la configuration des supports de stockage. En ce qui concerne l’accès aux VM, il reste protégé par les protections classiques telles que le couple login et mot de passe. Le passage dans des modes plus privilégiés attireraient inévitablement l’attention car cela nécessiterait des redémarrages non planifiés.

Conclusion

Traditionnellement, on considère qu’une technologie est sécurisée jusqu’à preuve du contraire. Il n’est pas utile de céder au sensationnalisme en décriant des potentielles failles qui n’ont pas été découvertes et qui n’ont jamais été exploitées (dans le cas de Xen).

Si nous suivons cette supposition traditionnelle, nous pouvons affirmer que la virtualisation est une technologie sécurisée. Comme toute technologie informatique, il est nécessaire d’être vigilant lors de son implémentation en suivant quelques règles de bon sens.

Pour revenir au sujet de la présentation effectué lors de la nuit du hack, j’ai été largement déçu par cette présentation aux conclusions au mieux hâtives et des nombreuses autres imprécisions que je n’ai pas évoqué ici.

La sécurité de la virtualisation

Antoine 4 commentaires

Ce weekend avait lieu la Nuit du Hack 2010. Il s’agit d’un événement orienté vers tous les types de hacking. De nombreuses conférences étaient proposées au public venu pour l’occasion avec notamment une présentation du hacking de l’iPhone et de la PS3.

Une présentation a particulièrement attiré mon attention mais pas pour de bonnes raisons. En fin de soirée avait lieu une conférence intitulé « Virtualisation et sécurité ». J’attendais donc avec impatience cette conférence. Autant dire que cela a été une grande déception. Le sujet était traité d’un point de vue beaucoup trop global mais, surtout, les informations soutenues étaient plus que discutables.

Je vais donc profiter de cette espace pour tenter d’éclaircir certains points par rapport à la sécurité de la virtualisation.

Classification

Avant de plonger dans l’étude à proprement dit de la sécurité dans la virtualisation, il est intéressant de se replonger dans la classification des solutions. Lors de la présentation, il avait été différencié les types de virtualisation suivants : « full virtualisation », « paravirtualisation » et « hyperviseurs ».

Un hyperviseur n’est pas un type de virtualisation mais une application qui peut effectuer de la virtualisation. Il est possible de les classifier selon deux catégories bien que cette division ne me plaise pas particulièrement.

La sécurisation de l’hyperviseur : DoS & DDoS

Lors de la présentation, le DoS (Denial of Service) et le DDoS (Distributed Denial of Service) ont été désignés comme des solutions simples et efficaces de neutraliser une plateforme de virtualisation.

Dans le cas de Xen, il est pratiquement impossible de communiquer avec l’hyperviseur. Il ne faut bien sur par confondre hyperviseur et domaine 0 (ou console de gestion dans le cas de VMWare). L’attaque DoS est donc difficile à imaginer dès le départ. L’interface de communication avec l’hyperviseur dont nous disposons est l’API des hypercalls, remplaçants des appels systèmes classiques dans le cas de la paravirtualisation.

L’utilisation des ces hypercalls est limitée par les algorithmes d’ordonnancement système ce qui empêche une utilisation abusive. Il s’agit du même mécanisme que celui utilisé pour le partage des ressources physiques. Le DoS semble donc impossible par ce biais.

Les outils d’administration sont également un potentiel point d’entrée supplémentaire. Ces outils ne sont accessibles qu’à partir du domaine 0 qui peut difficilement être considéré en tant que VM comme les autres. Un attaque DoS sur le domaine 0 rendrait les mêmes résultats qu’une attaque DoS sur les autres machines virtuelles étant donné les mécanismes d’ordonnancement.

La communication avec l’hyperviseur n’étant possible que par ces interfaces, il parait impossible d’y effectuer une attaque DoS capable d’atteindre toutes les machines virtuelles de la plateforme.

La sécurisation de l’hyperviseur : cloisonnement

Le cloisonnement des machines virtuelles est bien sûr une caractéristique élémentaire d’une plateforme de virtualisation. Contrairement à ce qui a été dit, l’hyperviseur n’a pas « la main » sur les machines virtuelles. Il a simplement la possibilité de les éteindre, de les démarrer ou de les mettre en pause. Ni plus, ni moins.

Le cloisonnement est géré par la restriction des accès mémoire. Les hyperviseurs ont été spécifiquement prévus afin d’éviter un débordement des accès vers la mémoire. Le seul vecteur d’exploitation de ce type de faille est les hypercalls dans le cas de Xen. A ce jour aucune faille connu permet d’accéder à des zones mémoires non autorisées.

De plus dans le cas de la virtualisation totale et de la virtualisation matérielle assistée, les machines virtuelles ne disposent même pas d’interface spécifique avec l’hyperviseur ce qui rend pratiquement impraticable de ce type de vulnérabilité.

Les risques d’erreur de cloisonnement ne sont pas inexistants bien entendu cependant il ne faut pas perdre de vue qu’il s’agit de l’objectif même de la conception de l’hyperviseur et que les machines virtuelles disposent de très peu ou aucune interface de communication avec l’hyperviseur afin de l’induire en erreur.

Dans le prochain (et dernier épisode), nous étudierons les autres points abordés lors de la présentation et les risques réels associés à la virtualisation. Loin de moi l’idée de prêcher la sécurisation totale de la virtualisation, je pense cependant qu’il est très facile et réducteur d’agiter des menaces sans fondement pratique.

La déduplication de données

Antoine 5 commentaires

Profitons de cette journée pluvieuse pour parler d’un peu de stockage. J’ai relativement peu l’occasion de parler de stockage sur ce blog bien que ce soit un sujet particulièrement intéressant, surtout dans le cas des réseaux de stockage. Ce n’est cependant pas de réseaux de stockage dont nous parlerons aujourd’hui mais de déduplication de données.

Notion de duplication

La notion de duplication de données est relativement simple. Prenons un jeu de données, la duplication de ces données donne un second jeu identique de données mais sur un autre espace de stockage. Il est possible de faire de la duplication dans le cas de la copie de disques ou de DVD par exemple. Il est également intéressant de faire de la duplication de données dans le cas de la virtualisation. Lorsque des machines virtuelles sont « provisionnées » ou bien, plus simplement, créées, une technique envisageable est la duplication d’une machine virtuelle « template ».

Dans le cas de la virtualisation, de nombreuses données sont présentes en plusieurs exemplaires. Sur une plateforme de virtualisation, il va être exécuté un certain nombre de systèmes d’exploitation. Un serveur de virtualisation standard aujourd’hui est capable d’exécuter 20 à 30 machines virtuelles. Supposons que ces machines virtuelles disposent de 2-3 systèmes d’exploitation différents, cela implique que 7 à 15 copies du même système d’exploitation vont être stockées.

Définition de la duplication

La déduplication va nous permettre de solutionner en grande partie ce problème. Cette technique a pour objectif de supprimer les doublons/triplons/etc du support de stockage afin de stocker qu’une seule copie des données. Il est possible d’implémenter cette technique à plusieurs endroits et à plusieurs niveaux. Prenons tout d’abord l’exemple de la mémoire vive et ensuite, l’exemple des disques.

Déduplication de la mémoire vive

La mémoire vive est un support de stockage d’information particulièrement couteux. Nous avons donc tout intérêt à en optimiser son utilisation. L’exemple que nous avons proposé plus haut pour illustrer la duplication des données est tout à fait valable pour les informations stockées en mémoire vive.

Le système d’exploitation va calculer une empreinte (« hash » pour les anglophones) pour une certaine unité de stockage pour la totalité de la mémoire vive. Lorsque le système rencontrera deux unités présentant la même empreinte, il en supprimera une copie et fera un lien vers l’unique copie. L’unité de stockage utilisée est, souvent, la page mémoire. Une empreinte est donc calculée pour chaque page mémoire et la déduplication se fait à ce niveau.

A ma connaissance, seuls les systèmes de virtualisation utilisent cette technique pour la mémoire vive. C’est, plus particulièrement, le cas de VMWare et de Xen 4.0.

Déduplication de disques

L’exemple de la mémoire vive est transposable aux supports de disque divers. La déduplication au niveau des disques va permettre les mêmes avantages que la mémoire vive et utilisera le même fonctionnement. La différence se situe principalement au niveau de l’unité de stockage qui sera choisie pour le calcul de l’empreinte. Le bloc sera, le plus souvent, utilisé pour les disques.

Une application réelle pour la déduplication se situe d’une part dans les systèmes de virtualisation mais aussi dans les systèmes de sauvegarde dans lesquels on peut retrouver de (très) nombreuses copies d’une même copie. Les équipements qui effectuent la déduplication sont les SAN mais aussi les systèmes de fichiers (« filesystem » pour les anglophones).

Vous allez me dire « Mais mon Linux il sait pas faire ca ! » et, oui, vous avez raison. Si vous voulez effectuer de la déduplication au niveau d’un système de fichiers, il va falloir utiliser ZFS sous OpenSolaris. J’en parlerais dans un prochain billet. Il serait prévu d’inclure ce type de fonctionnalité dans Btrfs.

Au final, j’espère avoir fait un tour d’horizon assez complet de cette technique relativement récente mais que je trouve particulièrement intéressante.