Top 20 du classement logiciel libre Wikio

En ce moment, ce blog ne déborde pas d’activité il faut bien le reconnaitre. C’est devenu assez compliqué pour moi de blogger ce semestre mais je vais essayer d’être plus régulier dans la publication de billets même si ca ne devrait pas être à une fréquence exceptionnelle. Aujourd’hui, ce ne sera pas un sujet technique pour une fois mais une petite parenthèse « blogosphere » disons.

Comme Wikio a régulièrement l’habitude de le faire, les classements des blogs traitant du logiciel libre sont publiés une journée en avance sur un blog inclut dans ce classement. Ce mois-ci ce sera donc à mon tour d’annoncer les 20 premiers du classement. Je vous laisse le consulter ci-dessous.

1 Framablog
2 WebDevOnlinux
3 Tux-planet
4 Philippe SCOFFONI
5 Toolinux
6 Le blog de NicoLargo
7 Ubuntu party
8 Ubuntu et Clapico
9 L’admin sous Linux
10 Blog de Devil505
11 Le Weblog de Frederic Bezies
12 L’esprit libre
13 System-Linux
14 Phollow.me
15 Another Pinky Punky
16 Le Mad Blog
17 ®om’s blog
18 Pouvoir choisir les logiciels libre
19 Monitoring-fr
20 Colibri

Classement développé par Wikio

Architectures de virtualisation

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.

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

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

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.

Blogiversaire !

Le premier article de ce blog date du 29 Mai 2009. Ca fait donc juste un peu plus d’un an que ce blog existe désormais ! Je sais, je l’ai raté de quelques jours mais je ne pensais vraiment pas que ca faisait déjà un an que ce blog existait. Un an de blog ca donne une occasion de faire un petit point sur le passé et l’avenir !

Bilan

L’objectif initial de ce blog était de m’occuper pendant mon stage de 4ème année qui devait durer 6 mois. Cet objectif bien que peu louable a été relativement bien rempli. Ce blog m’a permis de faire passer du temps lors de ce stage. Cet objectif a même été dépassé car je continue à écrire régulièrement ici même depuis la fin de ce stage et la reprise de mes études.

Un autre objectif était de partager des informations qui pourraient aider d’autres personnes tombant sur ce blog par divers biais. L’atteinte de cet objectif est relativement difficile à évaluer mais je souhaite croire que c’est le cas. Certains commentaires me l’ont confirmé. Commentaires auxquels j’essaye de répondre assez rapidement (peut être trop des fois d’ailleurs) grâce au Blackberry ainsi qu’au HTC Dream (désormais à la poubelle).

Au niveau des thèmes traités sur ce blog, je pense qu’ils sont assez fortement variés. Si on reprend l’en tête de ce blog, les sujets mentionnés sont les suivants : « Sécurité informatique, virtualisation, administration système et réseaux ». Quel programme ! Je ne pense pas avoir traité beaucoup de sécurité informatique ce qui est un tort car il s’agit d’un sujet qui m’intéresse particulièrement. J’ai beaucoup traité de virtualisation au début bien que ce sujet ait un peu été délaissé récemment. J’ai beaucoup parlé d’administration système récemment alors que j’en parlais relativement peu au début. Le réseau a été évoqué longuement à travers l’Utt Arena et les VRF.

Je pense que ce blog oscille entre ces quatre sujets en fonction de ma motivation ce qui est une bonne chose. Le cantonnement à un seul sujet sera particulièrement difficile à tenir et serait source de démotivation.

En ce qui concerne la gestion de mon identité numérique, j’estime que c’est un très bon début. Ce blog a fait disparaitre de la première page de Google bon nombre de résultats parasites. Pour le reste, on verra bien.

Quelques statistiques pour ceux que ca pourrait intéresser :

  • Nombre de pages vues : 55.000
  • Nombre de visiteurs : 30.000
  • Abonnés au flux RSS : 125

Avenir

J’entends bien entendu continuer ce blog sur cette lancée. Les échanges résultants sont très intéressants et me permettent de confronter ma compréhension de différents sujets à celle d’autres personnes.

Je souhaite tenter l’expérience qui consisterait à publier des billets n’ayant pas de rapport avec l’informatique mais avec mes autres activités.

J’ai déjà prévu d’effectuer une série de billets sur les réseaux de stockage car il s’agit d’un sujet exceptionnellement intéressant. J’ai également prévu de parler plus en détail d’OpenVPN car je passe pas mal de temps dessus en ce moment. Pour le reste, ce sera comme d’habitude, en fonction de mon humeur.

J’ai encore écrit un billet beaucoup trop long ! Je vais supposer que vous êtes habitués aux longs articles depuis le temps. Finalement, je vous remercie de lire mon blog car c’est grâce à cela que je trouve la motivation d’écrire.

Architecture réseau d’une LAN Party : Conclusion

Ce billet constituera la 8ème fois que nous parlerons de l’architecture réseau d’une LAN Party et plus particulièrement, l’Utt Arena 2010. Je souhaite conclure par ce billet cette longue série qui m’a permis de parler d’une bonne quantité de technologies diverses et variées.

Je ne referais pas de bilan spécifique car ce dernier a déjà été fait dans un billet précédent. Je n’ai pas d’élément à ajouter à ce que j’ai déjà dit précédemment. Malgré quelques problématiques humaines, je suis satisfait du réseau que nous avons mis en place lors de cette édition de l’Utt Arena.

Pour commencer cette conclusion, voici un récapitulatif de tous les billets de cette série :

Ensuite, je vous ai fait un paquet avec toutes les configurations des équipements. Il s’agit des configurations que nous avons sauvegardé à la fin de l’événement, elle n’inclut donc pas la configuration avant la transition vers les ASA. Pour rappel, les 3750 s’appellaient Kilimandjaro et StHelens et les ASA s’appellaient Etna, Kilauea, Fuji et Pinatubo.

Nous avons mis en place une weathermap lors de l’événement dont voici une capture. A ce moment, les joueurs tentaient de récupérer le GUI CS:Source. La bande passante du serveur étant limitée à 100Mbit/s, la montée en couleur a été réduite. Si vous souhaitez visionner la carte en taille réelle, il suffit de cliquer dessus.

Les résultats de Smokeping ont été également très satisfaisants. La capture d’écran ci-dessous montre un graph de la latence entre le serveur Smokeping et une interface IP d’une 3750 dans le LAN des joueurs. Les données avant le « trou » correspondent aux mesures faites avant la transition vers les ASA. On remarque un pic de latence suite à la transition. Cela correspond à la récupération du GUI par les joueurs et n’a donc pas impacté les tournois.

Pour ceux que cela pourrait intéresser, j’ai fait un paquet contenant de nombreux graphs que j’ai pu sauvegarder le dernier jour de la LAN avant de tout déconnecter. Il y a de nombreux graphs incluant notamment les uplinks vers les tables et les interfaces des ASA.

Au final, la gestion du réseau de cet événement fut un réel plaisir et m’a permis d’acquérir de nouvelles compétences notamment au niveau de l’utilisation des Cisco ASA et 3750 mais aussi des outils Cacti et Smokeping. Ici s’achève donc la plus longue série de billets de ce blog jusqu’à présent.