Les différents types de nuages

Après avoir tenté de définir le cloud computing et avoir évoqué les différentes technologies associés, nous allons nous intéresser aux différentes offres. Nous nous intéresserons à toutes les offres de la nature qui revendiquent un caractère de « cloud computing ».

Nous distinguerons trois types de nuages. Le premier type, également le premier à être apparu sous la dénomination « cloud », est le nuage public. Le second type est le nuage privé. Le dernier type est un mélange des deux, c’est à dire, un nuage privé-public.

Le nuage public

La dénomination de « cloud computing » est arrivée en même temps que les grands nuages publics. Ces grands systèmes informatiques ont été rendus viables grâce à une forte automatisation et une grande efficacité des couches de virtualisation.

Dans ce type de nuage, chaque client se voit attribuer plus ou moins aléatoirement une machine virtuelle dans laquelle il pourra faire ce qu’il souhaite. Ces machines virtuelles sont soumises aux contraintes définies par l’hébergeur en fonction de ses conditions générales de vente. Chaque machine virtuelle est sensée être l’égale d’une autre et le client n’a que très peu d’amplitude pour la construction d’une véritable architecture.

Les nuages publics existant aujourd’hui ont essentiellement vocation à être des plateformes d’hébergement grand public à la manière d’OVH sur le marché des serveurs dédiés. Pour que cette comparaison soit valable, il est nécessaire d’exclure la diversification des offres d’OVH avec notamment la possibilité d’obtenir un firewall Cisco ASA. Il est peu probable qu’il soit possible d’insérer un Cisco ASA dans un grand nuage public.

La présence de l’open source dans les nuages public est très forte, surtout à travers de Xen. Amazon, Gandi, 1&1 et Rackspace sont tous basés sur Xen. Le marché des grand nuages public a peu de chance de voir une réelle présence de VMWare à cause de sa tarification. Je vous laisse imaginer le prix d’un cloud public VMWare…

Le nuage privé

Les nuages privés sont clairement orientés vers les entreprises. Il parait particulièrement improbable de voir une quelconque entreprise confier la totalité de ses données et de l’infrastructure informatique à une nébuleuse telle qu’Amazon.

Il me semble que la notion de nuage privé est quasiment équivalente à la notion de plateforme de virtualisation interne à une société. Dans ce type de nuage, la notion de « cloud computing » semble floue et la distinction avec une plateforme de virtualisation semble mince voire inexistante.

L’open source a un rôle à jouer sur ce type de nuages mais l’état actuel des choses ne le facilite pas. L’automatisation d’une plateforme Xen ou KVM nécessite un travail de développement conséquent même si des outils tels que le Xen Cloud Platform vont dans le bon sens. VMWare est désormais très présent sur le marché avec ses produits d’administration et d’automatisation VSphere et Virtual Center.

Le nuage privé-public

Le nuage privé-public est un nuage privé inséré dans une plateforme public. Ce type d’offre est encore relativement rare car le concept est plutôt récent.

Cette notion semble relativement équivalente à la notion de nuage privé placé dans le cadre d’une offre d’infogérance. Bien que les offres placées sous la dénomination « nuage privé-public » sont rares, les plateformes de virtualisation infogérées sont monnaie courante aujourd’hui.

Au final, je pense avoir fait le tour des différentes configurations de « cloud computing » que l’on peut retrouver aujourd’hui. Je pense également que toutes ces offres ne sont pas réellement révolutionnaires contrairement à ce que bon nombre de commerciaux souhaiteraient nous faire croire.

Cloisonnement d’un réseau à l’aide de VRF : BGP

Tout d’abord, je souhaite vous souhaiter de bonnes fêtes car c’est la période de l’année habituelle pour le faire. J’espère également que le père Noël aura été généreux en jouets et gadgets électroniques de tous genres. Je vais profiter de cette journée calme au travail afin de vous écrire le dernier épisode de cette série d’article.

Rappel des épisodes précédents

Dans le premier épisode, je vous ai présenté l’architecture réseau qui avait été mise en place ainsi que les équipements. Nous avons également vu l’objectif que nous cherchions à atteindre. Pour rappel, l’objectif était de faire du cloisonnement de réseaux tout en gardant la possibilité de partager des routes entre ces réseaux. C’est pour cela que nous avions choisi d’utiliser les VRF.

Dans le second épisode, nous avons fait la création des VRF ainsi que la configuration IP des interfaces associées.

Protocole de routage : BGP

A la suite de ces deux épisodes précédents, nous avons une configuration IP basique. Afin d’atteindre l’objectif que nous nous étions fixé, il va être nécessaire de partager les routes entre les différentes VRF. Il ne suffira pas de partager toutes les routes à tout le monde car dans ce cas-là les VRF n’aura pas grand intérêt. Nous allons propager les routes de manière sélective.

Le protocole de routage permettant de propager les routes de manière très sélective parmi des VRF est le BGP. Ce protocole de routage ne sert pas uniquement à cela, loin de là. Le BGP est entre autre le protocole de routage utilisé par tous les routeurs de bordure d’Internet afin de propager la totalité des routes de l’Internet. Nous en utiliserons qu’une petite fonctionnalité dans le cas présent.

Afin de pouvoir propager les routes de manière sélective, il va être nécessaire de se baser sur un critère de sélection. Vous vous rappelez surement des « Route Distinguisher » ou RD. Les RD sont une sorte d’étiquettes appliquée aux routes d’une VRF spécifique. Nous allons donc pouvoir choisir les routes que nous propagerons et celles que nous propagerons pas.

Le schéma suivant récapitule les échanges de routes que nous allons effectuer.

Configuration des VRF

Nous allons donc configurer les VRF avec les import / export que nous avons défini dans le schéma ci-dessus. La configuration des VRF est assez explicite. Je ne pense pas qu’il soit possible de détailler plus que cela.

ROUTEUR2(config)# ip vrf client1

ROUTEUR2(config-vrf)# route-target export 200:1

ROUTEUR2(config-vrf)# route-target import 100:1

ROUTEUR2(config-vrf)# route-target import 400:1

ROUTEUR2(config)# ip vrf client2

ROUTEUR2(config-vrf)# route-target export 300:1

ROUTEUR2(config-vrf)# route-target import 100:1

ROUTEUR2(config-vrf)# route-target import 400:1

ROUTEUR2(config)# ip vrf prod

ROUTEUR2(config-vrf)# route-target export 100:1

ROUTEUR2(config-vrf)# route-target import 200:1

ROUTEUR2(config-vrf)# route-target import 300:1

ROUTEUR2(config-vrf)# route-target import 400:1

ROUTEUR2(config)# ip vrf interco

ROUTEUR2(config-vrf)# route-target export 400:1

ROUTEUR2(config-vrf)# route-target import 100:1

ROUTEUR2(config-vrf)# route-target import 200:1

ROUTEUR2(config-vrf)# route-target import 300:1

Configuration du BGP

Nous allons maintenant configurer le BGP afin de faire la distribution de route que nous souhaitons. Dans le cadre de la configuration de BGP, il sera nécessaire de définir une « address-family » par VRF. Une « address-family » est un groupe de configuration qui va permettre d’appliquer des directives spécifiques à un groupe de routes.

ROUTEUR2(config)# router bgp 1

ROUTEUR2(config-router)# no auto-summary

ROUTEUR2(config-router)# address-family ipv4 vrf prod

ROUTEUR2(config-router-af)# redistribute connected

ROUTEUR2(config-router-af)# synchronization

ROUTEUR2(config-router)# address-family ipv4 vrf interco

ROUTEUR2(config-router-af)# redistribute connected

ROUTEUR2(config-router-af)# redistribute static

ROUTEUR2(config-router-af)# synchronization

ROUTEUR2(config-router)# address-family ipv4 vrf client1

ROUTEUR2(config-router-af)# redistribute connected

ROUTEUR2(config-router-af)# synchronization

ROUTEUR2(config-router)# address-family ipv4 vrf client2

ROUTEUR2(config-router-af)# redistribute connected

ROUTEUR2(config-router-af)# synchronization

Cette configuration va nous permettre donc de propager les routes entre nos VRF. La prise en compte des modifications n’est pas forcément instantanée et peut prendre quelques minutes. Une fois le BGP configuré de cette sorte, il ne nous manque plus qu’une route : la route par défaut. Le BGP n’est pas un protocole réfléchi pour propager des routes par défaut. Il est cependant possible de lui forcer la main pour qu’il le fasse tout de même.

ROUTEUR2(config)# router bgp 1

ROUTEUR2(config)# default-information originate

ROUTEUR2(config-router)# address-family ipv4 vrf interco

ROUTEUR2(config-router)# default-information originate

Vous devriez voir toutes les routes appropriées dans les bonnes VRF. Les VRF clientes doivent donc avoir les routes vers les réseaux de prod et d’interco mais pas l’autre client. Les VRF d’interco et de prod doivent avoir une route vers l’un, l’autre et les VRF clientes.

Cet article clot la série des billets sur le cloisonnement de réseaux par le biais des VRF Cisco. Je vous ai uploadé les configuration que j’ai fait : Routeur1 & Routeur2.  Si vous avez des questions ou que vous pensez qu’il y a des imprécisions, n’hésitez pas à me le signaler par le biais des commentaires. J’espère que ce tutoriel vous aura été utile.

Cloisonnement d’un réseau à l’aide de VRF : Mise en place

stepfinal2Ce billet fait suite au premier billet traitant du sujet du cloisonnement d’un réseau à l’aide de VRF. Le premier billet avait pour objectif dans présenter la plateforme d’expérimentation que nous avons mis en place. Dans ce billet, nous allons nous intéresser à la configuration basique des équipements Cisco que nous avions à notre disposition. Dans un troisième et dernier billet, je présenterais la configuration du BGP permettant le propagation de routes sélectives entre les différentes VRF.

A titre de rappel, je vous renvois vers le précédent billet pour le schéma topologique qui vous permettra de comprendre plus facilement les configurations effectuées ici.

Configuration basique

Afin de pouvoir se retrouver plus facilement parmi tous nos équipements, nous allons paramétrer le nom d’hôte de nos différents équipements conformément au schéma.

ROUTER(config)# hostname ROUTEUR1

ROUTER(config)# hostname ROUTEUR2

Nous allons ensuite configurer les différentes interfaces IP de notre routeur de tête précédemment nommé ROUTEUR1.

ROUTEUR1(config)#interface Fa0/0

ROUTEUR1(config-if)#no ip address

ROUTEUR1(config-if)#shutdown

ROUTEUR1(config-if)#interface Fa0/1

ROUTEUR1(config-if)# ip address 192.168.100.1 255.255.255.0

ROUTEUR1(config-if)#exit

Nous allons ensuite configurer les routes statiques vers les réseaux raccordés directement sur notre second routeur. Il serait possible d’utiliser un protocole de routage mais par simplicité, nous avons choisi d’implémenter des routes statiques.

ROUTEUR1(config)# ip classless

ROUTEUR1(config)# ip route 192.168.0.101.0 255.255.255.0 192.168.100.2

ROUTEUR1(config)# ip route 192.168.0.102.0 255.255.255.0 192.168.100.2

ROUTEUR1(config)# ip route 192.168.0.103.0 255.255.255.0 192.168.100.2

La configuration de ce premier routeur se résume à ces commandes simples. Ce routeur est essentiellement un routeur témoin qui nous permettra de valider nos tests.

Configuration des VRF

Nous allons ensuite nous attaquer à la configuration des VRF sur notre second routeur. Pour rappel, les VRF sont des instances de tables de routage. Nous allons créer une VRF par zone de notre schéma. Nous en avons donc distingué 5 : client1, client2, prod et interco. Chaque zone aura donc sa propre VRF ce qui nous permettra d’avoir un cloisonnement finement paramétrable.

Tout d’abord, nous allons donc créer les VRF. Nous attribuerons un « Route Distinguisher » ou RD à chaque VRF. Un RD est un identifiant unique permettant d’identifier les routes associées à une VRF. Nous nous baserons sur ce critère lorsque nous ferons de la propagation de routes entre les différentes VRF.

ROUTEUR2(config)# ip vrf client1

ROUTEUR2(config-vrf)# rd 200:1

ROUTEUR2(config)# ip vrf client2

ROUTEUR2(config-vrf)# rd 300:1

ROUTEUR2(config)# ip vrf prod

ROUTEUR2(config-vrf)# rd 100:1

ROUTEUR2(config)# ip vrf interco

ROUTEUR2(config-vrf)# rd 400:1

Une fois toutes les VRF créées, nous allons configurer les différentes interfaces selon le schéma défini préalablement.

ROUTEUR2(config)# interface Fa0/0

ROUTEUR2(config-if)# description OUTBOUND

ROUTEUR2(config-if)# ip vrf forwarding interco

ROUTEUR2(config-if)# ip address 192.168.100.2 255.255.255.0

ROUTEUR2(config)# interface Fa0/1

ROUTEUR2(config-if)# description PROD

ROUTEUR2(config-if)# ip vrf forwarding prod

ROUTEUR2(config-if)# ip address 192.168.101.1 255.255.255.0

ROUTEUR2(config)# interface Fa1/0

ROUTEUR2(config-if)# description CLIENT1

ROUTEUR2(config-if)# ip vrf forwarding client1

ROUTEUR2(config-if)# ip address 192.168.102.1 255.255.255.0

ROUTEUR2(config)# interface Fa2/0

ROUTEUR2(config-if)# description CLIENT2

ROUTEUR2(config-if)# ip vrf forwarding client2

ROUTEUR2(config-if)# ip address 192.168.103.1 255.255.255.0

ROUTEUR2(config)# ip route 0.0.0.0 0.0.0.0 192.168.100.1

Nous avons donc configuré les différentes interfaces, les différentes VRF ainsi que l’association des VRF aux interfaces. Si nous n’avions pas eu suffisamment de ports physiques, il vous est tout à fait possible de créer des sous-interfaces 802.1Q qui fonctionneront de manière identiques aux interfaces physiques.

Dans le prochain billet, je détaillerais la configuration du protocole de routage afin de redistribuer les routes de manière sélective parmi toutes nos VRF.

Articles de la série

Configurer un switch Cisco sous MacOS

CISCO LOGOCela fait désormais un an que je suis utilisateur assidu de MacOS. J’ai toujours réussi à faire ce que je faisais sur PC sur MacOS à quelques exceptions près. Ces deux exceptions sont les jeux 3D spécifiques Windows (Flight Simulator entre autre) et l’administration d’un équipement réseau via port série.

Les MacBook Pro ne sont pas dotés d’un port série. J’ai donc du commander un adaptateur USB-Série sur Ebay pour une somme tout à fait correcte dont je ne me souviens plus. On en trouve actuellement pour moins d’une dizaine d’euros. Vous allez cependant devoir vous armer de patience car ils sont le plus souvent expédiés de Chine. Voici à quoi ressemble ce fameux adaptateur.

usbserie

Il fonctionne parfaitement sous Ubuntu. Je n’ai eu aucune difficulté particulière. Une simple recherche Google et l’installation d’un driver a suffit pour le faire fonctionner. Je souhaitais cependant le faire fonctionner sur mon MacBook car il est quand même bien plus pratique de déplacer un portable qu’une tour.

La première action à effectuer est de récupérer le pilote adapté à l’adaptateur que vous avez acheté. Le problème est qu’il n’y a strictement rien marqué dessus. Ayant précédemment fait l’installation sous Ubuntu, j’avais réussi à déterminer qu’il s’agissait d’un PL2303. Ces adaptateurs semblent très répandus. Il y a donc beaucoup de chances que si le votre ressemble au mien, ce soit la même chose. Vous trouverez le pilote du PL2303 sur le site d’Apple. Vous allez devoir redémarrer votre poste pour finaliser l’installation du pilote.

Ensuite, il va falloir se connecter au périphérique que vous avez raccordé à l’autre bout de votre câble série. Sur Windows, vous auriez eu HyperTerminal qui remplit très bien ses fonctions. Sur MacOS, il est visiblement possible de faire fonctionner Minicom. Je n’ai pas du tout réussi… Fink et apt-get n’ont pas réussi à le trouver dans leurs dépôts. Je me suis donc lancé dans l’utilisation de screen. Dans mon cas, mon adaptateur était reconnu sous le nom /dev/cu.PL2303-00002006.

Il va falloir aller configurer les paramètres du port série du système. Dans le fichier /etc/gettytab, vous devriez trouver des lignes commencant par « serial. « . Effacez (ou commentez) toutes celles ne contenant pas 9600. Sauvegardez le fichier et exécuter la commande suivante :

stty -f /dev/cu.serial

Si la première ligne de la réponse est « speed 9600 baud; », votre port série est bien configuré. Vous pouvez ensuite accéder au périphérique en exécutant la commande suivante :

screen /dev/cu.PL2303-00002006

Vous devriez pouvoir accéder à votre périphérique. Une fois que vous aurez fini la configuration, vous pouvez quitter le screen en tapant « Cmd A » puis « Cmd . ».

Je pense que ce tutoriel devrait être utile à quelques personnes car cette configuration n’est pas forcément aisée à faire. Je me suis aidé d’un sujet sur le site d’Apple et d’un tutoriel du site MacOSHints.

Un peu de QoS avec Pfsense

J’ai déjà eu l’occasion de vous parler de Pfsense dans un précédent billet. Pour rappel, il s’agit d’une distribution basée sur FreeBSD qui a pour objectif de founir différents services réseau. Cette distribution brille par sa simplicité d’utilisation et par son nombre conséquent de fonctionnalités.

pfsense-logo

Un des grands avantages de Pfsense est de disposer d’un système de gestion de paquets. Ce système permet de pouvoir facilement rajouter des applications tierces.

Dans notre cas, nous avons un LAN qui contient un certain nombre de postes. Le problème de ce LAN est qu’il a la fâcheuse tendance de consommer toute notre bande passante. Nous allons donc devoir implémenter une solution de QoS. La QoS est un ensemble de techniques qui consiste à mettre une priorité à du trafic et à contrôler la bande passante allouée à ce trafic. Il existe bien sûr de nombreux boitiers commerciaux qui sont capables d’assurer ces fonctionnalités mais leur prix est pour le moins prohibitif.

Le trafic que nous aurons à gérer est essentiellement du trafic web (HTTP et HTTPS). Les contraintes sur la QoS sont qu’il va être nécessaire de plafonner le débit utilisable à 10Mbit/s et d’éviter qu’un utilisateur puisse saturer toute la bande passante.

Squid semble être la solution idéale pour faire ce que nous avons à faire. Etant donné que nous allons traiter que des flux web, le proxy web semble être la meilleure solution. Pfsense est capable de faire de la QoS sur des paquets  mais les options ne sont pas aussi poussées que lors de l’utilisation d’un proxy. Avec la QoS standard, nous n’aurions pas pu garantir qu’un utilisateur ne puisse pas saturer toute la bande passante par exemple.

On va donc installer le package Squid :

pfsensepackages

Une fois le package Squid installé, nous allons pouvoir paramétrer le proxy web que nous venons d’installer. Vous devriez pouvoir y accéder dans le menu services comme illustré dans l’image suivante :

pfsenseproxy

Dans la page principale de configuration, nous allons pouvoir configurer les différentes options de notre proxy. Il est intéressant de vérifier les interfaces sur lesquelles il va répondre et le port d’écoute. Il faut ensuite définir les plages d’IP autorisées à utiliser ce proxy dans l’onglet « Access Control ». Nous allons ensuite pouvoir nous attarder sur la configuration de la QoS.

Tout d’abord, il faut se rendre dans l’onglet « Traffic Management » dans lequel nous allons pouvoir effectuer tous nos paramétrages. Nous allons pouvoir paramétrer la bande passante maximale utilisable par les utilisateurs de notre proxy en renseignant le champ « Overall Bandwidth Throttling ». Afin d’éviter qu’un utilisateur puisse consommer toute la bande passante, nous allons donc paramétrer une limitation par utilisateur. Nous allons supposer qu’il n’y a jamais plus de 3 utilisateurs qui essayent de consommer beaucoup de bande passante. Nous pouvons donc mettre 3Mbit/s. L’image suivante résume le paramétrage :

pfsensethrottling

Une fois les paramètres pris en compte, nous aurons un proxy web qui régulera et limitera la bande passante utilisé par nos utilisateurs qui passeront par ce proxy. Nous avons également la possibilité de rajouter des fonctions de filtrage web avec le plugin SquidGuard et une blacklist adaptée. Il est également possible de mettre le proxy web en mode transparent en cochant une option dans les options générales du proxy.

Les anneaux de protection système

800px-Olympic_Rings.svgLa série d’articles sur la détection d’intrusion m’aura permis de faire une petite coupure dans la série d’articles sur la virtualisation. Je vais donc reprendre les articles sur la virtualisation. Pour rappel, la plupart des ces articles sur la virtualisation reprennent le contenu de l’AC que j’ai effectué avec Romain Hinfray. Ces articles me permettent de prendre un peu de recul par rapport à cette AC et de compléter avec de nouvelles connaissances.

Avant de pouvoir continuer sur la virtualisation, je souhaite faire un article qui servira de pré-requis à la suite. Je vais parler des anneaux de protection (ou rings pour les anglophones). Cette notion n’est pas seulement utile en virtualisation mais plus largement en systèmes d’exploitation.

Principe des anneaux de protection

Vous avez surement entendu parlé de « Rings » ou d’anneaux si vous avez déjà fait un peu de sécurité des systèmes d’exploitation, de la virtualisation ou de l’électronique informatique. On parlera ici d’anneau de protection afin d’éviter les termes anglophones, nous parlons en Français tout de même. Comme vous commencez sans doute à vous en douter, nous serons ici sur du « bas niveau » au niveau des systèmes d’exploitation.

Nous étudierons tout d’abord l’utilité des anneaux de protection. Comme leur nom l’indique, ils ont pour objectif de fournir une fonction de protection. Cette protection s’applique sur les divers composants applicatifs du système d’exploitation. L’objectif va être d’empêcher divers composants applicatifs d’un système d’exploitation de se modifier entre eux. Vous comprendrez donc qu’une modification d’un composant applicatif par un autre est synonyme de faille de sécurité.

Les composants qui vont nous intéresser plus particulièrement dans le cadre d’un système d’exploitation sont le noyau et les applications. Autant il est tout à fait envisageable que le noyau puisse apporter des modifications aux données dynamiques d’une application, l’inverse l’est beaucoup moins. Ces données dynamiques sont les données stockées en mémoire vive. La mémoire vive est systématiquement amenée à contenir le programme lui-même ainsi que les données qu’il traite. Vous comprenez donc bien l’intérêt d’une protection ou plutôt d’un cloisonnement.

Application aux systèmes x86-32

Dans les systèmes x86-32, il existe 4 anneaux de protection numérotés de 0 à 3. Dans la quasi-totalité des systèmes d’exploitation sans virtualisation, seuls les anneaux 0 et 3 sont utilisés. L’anneau le plus privilégié est l’anneau 0 qui contient le noyau du système d’exploitation. L’anneau le moins privilégié est l’anneau 3 qui contient les applications et leurs données dynamiques. Les deux autres anneaux ne sont pas utilisés. Ils l’ont été dans OS/2 ou bien Netware pour y placer différents pilotes. Le schéma ci-dessous reprend la répartition des composants applicatifs dans un système d’exploitation moderne.

rings

Application à la paravirtualisation

Dans le cadre de la paravirtualisation, le système d’exploitation ne sera pas le premier intermédiaire du matériel mais ce sera l’hyperviseur. Pour des raisons de sécurité, il sera nécessaire de cloisonner le système d’exploitation et l’hyperviseur. Dans ce cas-là, il sera fait usage de l’anneau 1. Nous placerons donc l’hyperviseur dans l’anneau 0 et le système d’exploitation dans l’anneau 1. Les applications restent bien au chaud dans l’anneau 3.

Implémentation des anneaux de protection

Maintenant que je vous ai expliqué tout ceci, l’utilité et l’application des anneaux de protection semble clair. Il manque cependant un élément clé de la compréhension de ce concept : l’implémentation des anneaux de protection. Comment se concrétisent les anneaux de protection ? Où se trouvent-ils dans la nature ?

Les anneaux de protection sont implémentés au niveau de la mémoire vive. Une zone de mémoire vive se voit attribuer une localisation dans un anneau par le système d’exploitation. Un programme contenu dans une zone mémoire attribuée à l’anneau 3 ne pourra pas aller modifier une zone mémoire attribuée à l’anneau 0.