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.

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.

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.

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 :

• Architecture réseau d’une LAN Party : Introduction
• Architecture réseau d’une LAN Party : Conception
• Architecture réseau d’une LAN Party : Filtrage
• Architecture réseau d’une LAN Party : Configuration des ASA
• Architecture réseau d’une LAN Party : DHCP
• Architecture réseau d’une LAN Party : La latence
• Architecture réseau d’une LAN Party : Premier bilan

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.

Phase 1

Tout d’abord, nous n’avions pas la possibilité d’avoir les équipements réseau type Cisco ASA et 2800 avant le Samedi midi car ils n’arrivaient pas avant ce moment là. Nous avons donc du faire avec une solution secondaire par le biais des 3750. Cela était parfaitement prévu depuis quelques semaines mais je n’avais pas souhaité en parler afin d’éviter l’effet placebo lors de la transition vers le réseau définitif.

La mise en place des deux 3750 s’est faite sans aucun soucis particulier. Le premier 3750 nommé Kilimandjaro disposait d’une interface IP dans tous les VLAN et effectuer le routage entre ces derniers. Le second 3750 nommé StHelens avait pour seule fonctionnalité la commutation des paquets associées à ses interfaces. Nous avions également prévu ce second 3750 afin d’avoir une solution de secours en cas de panne du premier 3750.

Transition

Lorsque les ASA sont arrivés, nous avons dû effectuer la transition du réseau initial vers le réseau prévu. Les joueurs n’ont pas été mis au courant de ce changement afin d’éviter un effet placebo qui correspondrait à voir des pannes partout sans réelle raison. Les organisateurs ont cependant été mis au courant ce qui a provoqué une avalanche de remontées de problèmes divers et, en grande partie, sans aucun rapport avec transition. La gestion des remontées de ces problèmes a été plutôt mauvaise car tous les organisateurs remontaient vers l’équipe réseau tous les problèmes, incluant ceux n’ayant aucun rapport de près ou de loin avec le réseau.

Nous avons racké les ASA dans la baie prévue à cet effet. J’évoquerais l’architecture physique ultérieurement. Nous avons ensuite injecté les configurations en port série et nous avons validé que nous avions bien un accès Telnet à ses équipements afin d’éviter de mauvaises surprises. Nous avons ensuite connecté tous les ports de Management et d’interconnexion des ASA afin qu’ils prennent connaissance de la topologie IP. Nous avons ensuite basculé les interfaces IP du 3750 vers les ASA une par une. Nous avons tout de même laissé une interface par VLAN sur les 3750 pour la fonctionnalité DHCP. Pour les routeurs, nous avons appliqué une méthodologie similaire.

Lors de la transition, nous avions donc une partie des VLAN routés par le 3750 et une partie des VLAN routés par les ASA/2800. Cette configuration temporaire a impliqué un routage asymétrique. Autant les routeurs sont peu sensibles aux asymétries de routage, les ASA ne le sont pas car ils effectuent un suivi de la session TCP. Nous avons réussir à contenir en bonne partie l’asymétrie du routage en jouant avec les identifiants de routeur OSPF ou du moins on pense que ce fut le cas. De toute manière, la transition a duré une petite heure.

Une fois la topologie reconstituée, nous avons coupé l’OSPF sur le 3750 afin qu’il soit exclu du processus de routage et nous avons laissé les ASA et les 2800 faire leur travail. Une coupure d’une trentaine de secondes est induite par la réélection OSPF et le recalcul des routes.

Phase 2

Une fois toute l’architecture en place, nous avons pu commencé à débugger nos configurations. Nous avons essentiellement eu des soucis de configuration de VLAN sur les switchs que nous avons mis un peu de temps à corriger. Les remontées de problèmes pertinentes ont mis un peu de temps à nous parvenir réellement car elles étaient noyées dans un volume assez important de demandes.

Nous n’avons pas rencontré de problème particulier lié à notre architecture réseau suite aux reconfigurations initiales. Les joueurs Warcraft III ont rencontré de nombreux problèmes de connexion aux parties alors qu’ils étaient tous dans le même VLAN voire sur le même switch. Nous n’avons pas réussi à déterminer l’origine de ce problème épisodique. La piste d’un applicatif malicieux est privilégiée car de multiples changements de switch et un passage en IP fixe n’ont apporté aucune solution à ce problème. La latence est tout à fait correcte selon nos mesures bien que nous rencontrons quelques problèmes du coté des serveurs CSS qui se montrent quelque peu capricieux. Nous avons mis le LLQ pour le principe mais la différence de latence ne parait pas significative.

Au final, la préparation nous a permis d’effectuer une transition propre et plutôt efficace. La vraie difficulté a été la qualification et la pertinence des problèmes remontés aux administrateurs réseaux. Je referais un point une fois l’évènement passé.

L’Utt Arena c’est demain. Ca fait toujours un choc de se rendre compte de ca je trouve. Nous avons fait une dernière séance de préparation hier soir afin de régler les derniers aspects de réseau. Nous avons vérifié le fonctionnement des accès Telnet aux équipements afin de pouvoir les administrer le jour J, nous avons validé les configurations des routeurs 2800 et des 3750. Nous avons également testé le fonctionnement de notre sonde de mesure de la latence dont je parlerais plus en détail aujourd’hui. Nous sommes prêts. Nous avons réussi à faire et à tester tout ce que nous souhaitions effectuer avant l’événement. Pour le reste, on donnera le meilleur de nous-même.

Je vais faire le maximum pour essayer de faire au moins un retour d’expérience pendant l’évènement pour ceux que ca pourrait intéresser. Je ne garantis pas que ce sera extraordinaire car la fatigue et la déconcentration devront être de la partie. De toute manière, je ferais un retour d’expérience une fois l’évènement passé et après avoir débriefé avec mon équipe.

La latence est l’intervalle de temps entre l’émission d’un requête et la réception de la réponse. La notion de latence peut s’appliquer à toutes les applications impliquant un ou plusieurs intermédiaires. Il s’agit d’une notion clé lors d’une LAN Party. Les joueurs passent un temps non négligeable les yeux rivés sur l’indicateur de latence.

Les facteurs influant sur la latence sont la congestion réseau, surtout dans le cas d’applications UDP, les temps de calcul des équipements intermédiaires et la qualité du support physique. La congestion réseau est un vrai problème en LAN car des fichiers ont tendance à circuler entre les différents ordinateurs. Nous avons solutionné largement ce problème en appliquant des ACL de filtrage lorsque les tournois ont lieu. La qualité du support phyisque est un problème réduit dans le cas des réseaux câblés mais peut néanmoins intervenir lorsque les câbles sont maltraités.

Le temps de calcul des équipements intermédiaires est une réelle problématique sur laquelle il est relativement difficile d’agir. Dans le cas de commutateur, le temps d’exécution de l’algorithme de commutation est minime mais peut augmenter avec la montée du CPU du commutateur. Dans le cas d’un routeur, les algorithmes sont plus longs. Pour éviter cela, nous avons implémenté un mécanisme de QoS (LLQ).

Habituellement, nous sommes dans le flou concernant les temps de latence. La seule indication que nous avons habituellement est l’affichage du « ping » sur Counter-Strike ce qui fournit une mesure peu représentative de l’état du réseau. Nous avons donc décidé d’implémenter l’outil SmokePing. Cet outil a été conçu afin de mesurer la latence entre un serveur et différents points du réseau. L’installation de cette application est particulièrement simpliste, de même pour la configuration.

La plus-value de Smokeping est l’étude statistique qu’il effectue sur les valeurs de la latence. Les solutions traditionnelles de supervision se contentent d’afficher une unique valeur de latence. Smokeping vous affiche la distribution statistique de vos valeurs afin d’avoir une idée plus claire de la latence mais aussi de la gigue sur votre réseau. Vous trouverez ci-dessous un exemple de graph que j’ai pu trouver sur Internet. Les barres bleues correspondent aux valeurs de perte de paquets. Les valeurs vertes correspondent à la médiane de latence et les valeurs noires la distribution statistique.

Nous allons mesurer la latence entre un serveur placé dans le LAN des Serveurs et une interface IP du 3750 dans le LAN des joueurs. Ce mode de mesure ne prend pas en compte la latence induite par la congestion des uplinks des tables. Hélas, nous n’avions pas la possibilité de faire autrement sans placer des machines sur les tables. Afin d’observer la congestion réseau sur les liens, nous aurons une weathermap Cacti. Nous mesurerons donc le temps de traversée des routeurs et des ASA, ce qui est déjà un bon début.

Au final, la latence est un aspect réellement primordial d’une LAN. Nous avons décidé de mettre en place un système de mesure efficace afin d’avoir de véritables valeurs et de pouvoir différencier les vrais problèmes de l’effet placebo ou d’une imagination débordante. Smokeping est vraiment un outil excellent d’une simplicité exceptionnelle.

Comme d’habitude, faisons un point d’avancement avant de rentrer dans la discussion technique. Le jour J est ce Vendredi soir donc nous nous retrouvons rapidement au pied du mur. Nous sommes cependant prêts à mettre en place l’architecture que nous avons prévu. La dernière de séance de préparation a été assez confortante car nous avons réussi à mettre en place l’architecture rapidement et effectuer les différents ajouts rapidement. Nous avons du apporter des modifications significatives à l’architecture dont je parlerais dans un prochain billet.

J’en avais déjà parlé lors du billet sur la conception de ce réseau, nous avons prévu de mettre en place un certain nombre de VLAN. Traditionnellement, un seul serveur DHCP était nécessaire afin d’allouer des adresses IP à toute la LAN. Or dans le cas présent, nous sommes loin de cette configuration.

Une première solution, assez primitive, aurait consisté à placer un serveur DHCP dans chaque VLAN. Cette solution est, bien évidemment, pas envisageable de par sa complexité de gestion et de sa consommation en machines. Il aura été possible de comprimer cette solution en utilisant des machines virtuelles mais nous n’avons pas de machine suffisamment puissante afin de faire celà.

La seconde solution, la plus évidente, est d’utiliser les ASA afin d’attribuer les bails DHCP. Cette idée est particulièrement efficace car elle permet de regrouper la configuration en un seul point. Les ASA sont parfaitement capables d’assurer la fonctionnalité DHCP pour plusieurs LAN. Ils peuvent allouer des IP inclues dans une plage sur chaque interface. Ce qui est cependant franchement ridicule, ils ne sont capables d’attribuer qu’une seule passerelle par défaut pour tous les LAN. Concrètement, vous pouvez allouer IP et Passerelle pour un LAN mais que des IP pour tous les autres LAN. Nous ne pouvons donc pas utiliser les ASA afin de servir d’allouer des bails DHCP décemment.

La solution finale est d’utiliser des Cisco 3750 afin d’attribuer des bails DHCP. Les 3750 sont des switchs avec une grosse dose d’intelligence supplémentaire. Ils sont capables, en plus de commuter, de router, de gérer un (ou plusieurs) protocoles de routage et d’allouer des bails DHCP pour plusieurs LAN. Cette solution implique que les 3750 aient une interface IP valide dans chaque LAN.

La configuration DHCP des 3750 est particulièrement simple à effectuer. Il faut d’abord créer l’interface IP associée au VLAN. Dans cet exemple, nous créons une interface IP associée au VLAN n°50 qui aura pour IP 10.5.0.5

interface Vlan50
description Admin
ip address 10.5.0.5 255.255.255.0

Il faut ensuite indiquer au switch la plage d’IP qu’il peut allouer sur cette interface ainsi que la passerelle par défaut.

ip dhcp pool 50
network 10.5.0.0 255.255.255.0
default-router 10.5.0.1

Nous pouvons ensuite exclure une plage d’IP qui servira pour adresser divers équipements réseau : ASA et 3750 dans notre cas.

ip dhcp excluded-address 10.5.0.1 10.5.0.10

Au final, la configuration DHCP des Catalyst 3750 est relativement simple. Afin d’adresser de nombreux VLAN, il suffit de répéter le processus précédent. Ensuite, il suffit de placer les joueurs dans le bon VLAN et ils obtiendront les informations de configuration réseau.

Un barcamp aura donc lieu à la Halle Sportive de l’Université de technologie de Troyes ce Samedi à partir de 17 heures. Il aura lieu en marge de l’Utt Lan Session qui est une LAN Party organisée par l’Utt Net Group. Il devrait durer jusqu’à 22 heures environ. Une pause pour manger est prévue afin de pouvoir reposer vos neurones.

En ce qui me concerne, j’aurais l’occasion de vous faire une présentation « tour d’horizon » sur les réseaux de stockage. Vous pourrez également participer à de nombreuses autres présentations parmi les suivantes :

• VBA
• SOAP
• OpenID & OAuth
• OpenPGP
• LDAP
• CNIL
• Trap your process

N’hésitez pas à venir faire un tour et nous rencontrer ce weekend à Troyes. Vous trouverez toutes les infos nécessaires par rapport à cette manifestation sur le site de l’ULS.

Récapitulatif

• Quoi ? Un barcamp
• Quand ? Samedi 28 Novembre à partir de 17h jusqu’à 22h
• Où ? A la Halle Sportive de l’Université de technologie de Troyes
• Pour qui ? Tout le monde qui souhaite partager avec nous