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

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

stepfinal2Je vais commencer une nouvelle série d’article plus orientée vers le réseau. Je n’ai eu que relativement peu d’occasions de parler de réseau sur ce blog mais je vais me rattraper quelque peu. Cette série devrait comporter 3 articles voire peut être un peu plus, en fonction de mon humeur. Elle est le résultat d’une journée d’expérimentation effectuée avec un collègue dans le cadre de mon stage. Dans ce billet d’introduction, je vais présenter l’objectif de l’expérimentation, le matériel utilisé et la topologie.

La problématique

Lorsque nous nous sommes lancés dans ces expériences, nous avions un objectif bien précis correspondant à la réalité d’une architecture actuellement en production. La problématique était d’isoler au niveau IP plusieurs clients pouvant potentiellement avoir des plages d’IP similaires. Plus concrètement, l’objectif était d’isoler chaque client dans sa « bulle de routage » afin de pouvoir avoir une plus grande liberté dans l’évolution de l’architecture et dans l’intégration de nouveaux clients.

Nous savions déjà qu’il était possible de résoudre le problème d’isolation par le biais des VRF de Cisco. Pour rappel, une VRF est une « bulle de routage » spécifique à un groupe de ports. Typiquement, une VRF correspond à un client spécifique. La véritable difficulté venait du fait que nous souhaitions également qu’il soit possible de communiquer de manière sélective entre les différentes VRF.

Le matériel utilisé

Afin de pouvoir tester la mise en place de cette idée, nous avons ressorti des équipements Cisco qui se trouvaient fortuitement sur notre chemin. Ce jour là, notre chemin a rencontré deux Cisco 7204 VXR ainsi que deux Cisco 2970G. Chaque 7204 VXR était doté d’une carte de supervision avec 2 ports 100Mbit/s ainsi que d’un module 1 interface 100Mbit/s supplémentaire. Nous avons donc mélangé tout ce matériel pour faire deux routeurs différents : le « Routeur 1  » sans module supplémentaire et le « Routeur 2  » avec les deux modules supplémentaires.

Voici une petite photo du montage que nous avons effectué.

matosLe « Routeur 1  » était le routeur du haut et le « Routeur 2  » était le routeur du bas. Au niveau des switchs, nous n’avons utilisé que celui du bas. Les ports 1 et 2 servaient pour le réseau « Interco ». Les ports 13 à 16 étaient le VLAN de Prod. Les ports 17 à 20 étaient le VLAN Client 1. Les ports 21 à 24 étaient les VLAN Client 2. Le câble permettait de relier le PC de test.

Topologie logique

Le schéma suivant représente la topologie logique que nous avons mis en place.

SchemaGlobalSmall

Le « Routeur 1  » est le routeur qui pourrait faire office de routeur de sortie vers Internet. La route par défaut de notre réseau pointera sur lui. Le « Routeur 2  » est le routeur « coeur » qui arbitrera toutes les VRF et les échanges de routes. Les trois switch du bas du schéma sont les différents LAN de nos clients. L’objectif sera de faire communiquer les LAN client avec le routeur 1 et le LAN de Prod.

Au final, cet article avait pour objectif de vous présenter la topologie et la problématique. Le prochain article s’attachera  la configuration des équipements et la mise en place des VRF.

Articles de la série

Aller plus loin que Linux : Solaris

Je vais commencer une nouvelle série de billets sur un système d’exploitation alternatif à Linux. Je ne parlerais pas ici de Windows car mes compétences dans ce système d’exploitation sont fortement limités. Je vais parler de Solaris édité par Sun Microsystems. Je m’attacherais dans un premier temps à faire un tour d’horizon des éléments qui rendent intéressant ce système d’exploitation.

solaris-logo

La plupart de mon expérience en administration système s’est faite autour de la distribution Linux Debian. Debian est une distribution qui je trouve particulièrement simple à utiliser. Les développeurs de cette distribution ont pris un soin particulier de simplifier les différentes taches d’administration système. Ceci passe par une gestion claire et simplifiée des répertoires systèmes mais surtout par un gestionnaire de paquets apt-get. J’ai également eu l’occasion d’utiliser CentOS et Red Hat qui sont pratiquement identiques. L’environnement de cette distribution est également largement simplifié avec une gestion simplifiée des répertoires systèmes et divers utilitaires visant à simplifier l’administration système. Je ne pourrais pas dire que le gestionnaire de paquets inclus dans ces distributions simplifie réellement la vie car je n’ai jamais réussi à le faire marcher correctement.

Un inconvénient fréquemment évoqué par rapport à ces distributions est le fait qu’il est plus difficile de comprendre le mécanisme de fonctionnement du système d’exploitation. Ceci est lié à la simplification des taches d’administration et n’est pas forcément un inconvénient a priori. Cette simplification devient problématique lorsqu’il s’agit de faire du débuggage dans un système de production qui présente un comportement bizarre. Les messages d’erreurs standards sont relativement faciles à diagnostiquer mais lorsque le problème est moins « franc », les choses se corsent. J’adhére partiellement à cet inconvénient. Je souhaitais surtout obtenir une connaissance plus approfondie d’un système d’exploitation. Je me suis donc penché sur Sun Solaris.

Lorsque l’on commence à s’intéresser à Solaris, les choses sont relativement claires dès le début, on va avoir à faire à un Unix dit « traditionnel ». Ceci signifie que les repères acquis sous Linux vont disparaitre totalement et que les outils de simplification seront soit incomplets soit inexistants. D’un autre coté, Solaris est un système d’exploitation qui a de nombreux arguments en sa faveur. Vous avez surement entendu parler de ZFS, le système de fichier révolutionnaire. Vous avez peut être entendu parler de DTrace qui vous donne une vision approfondie du fonctionnement de votre système d’exploitation. Vous avez peut être entendu parler des zones Solaris et de l’intégration native de Xen sous le nom xVM. Et encore, nous n’avons parler de SMF. Bref, autant dire que les arguments sont bien présents.

Solaris permet de s’affranchir des outils et couches de simplification d’un système d’exploitation Linux et de se plonger réellement dans la compréhension du fonctionnement d’un système d’exploitation Unix. Afin de réussir à l’utiliser correctement, il va être nécessaire de comprendre les mécanismes internes. Ceci est un chantier tout à fait passionnant que je vous encourage à entreprendre. Vous ne serez pas seul dans cette entreprise, Sun a prévu pour vous des documentations particulièrement claire et explicite que vous trouverez sur leur site. Sun a également prévu un cursus de certification accessible gratuitement sur leur site. Le passage de l’examen est payant par contre pour la modique somme de 40€.

Mais, pourquoi pas Gentoo ou BSD ? Ces distributions permettent certes de comprendre plus en profondeur le fonctionnement d’un système d’exploitation mais n’ont pas les arguments qu’a Solaris ni la documentation ni le parcours de certification. Je ne dis pas que s’intéresser à Gentoo ou BSD n’aurait eu aucun intérêt, loin de là. J’ai juste préféré changer d’orientation vers une distribution, certes un peu moins libre, radicalement différente.

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 dans le cas du 64-bit

800px-Olympic_Rings.svgDans le billet précédent, j’ai eu l’occasion de vous présenter les anneaux de protections système et leur utilité dans le cas de la virtualisation. Je vais continuer avec ce billet évoquant les spécificités du 64-bit.

Si vous avez lu mon précédent billet sur la virtualisation matérielle assistée, vous avez dû remarquer que je parlais de l’ajout de l’anneau « -1 ». Sauf qu’un précédent billet sur les anneaux de protection système n’évoquait que les anneaux de 0 à 3.

L’architecture historique, à savoir, l’architecture x86-32 dispose effectivement de 4 anneaux numérotés de 0 à 3. Cependant seuls deux anneaux étaient utilisés : un pour le système d’exploitation et un pour les applications. Lorsqu’AMD et Intel ont refondu l’architecture x86 pour passer au 64-bit, ils ont décidé de supprimer les anneaux 1 et 2. Il ne resta donc plus que les anneaux 0 et 3.

Ceci n’a pas créé de problème particulier car ces anneaux n’étaient pas utilisés dans les systèmes d’exploitation. La virtualisation est arrivée relativement peu de temps après et avait pour habitude d’utiliser un anneau supplémentaire afin de cloisonner l’hyperviseur, le système d’exploitation et les applications. Les solutions de virtualisation se sont donc retrouvées avec deux anneaux alors qu’il était plus simple et plus sécurisé d’en utiliser trois. Afin de résoudre cette problématique, dans le cas du projet Xen, l’anneau 3 a été mutualisé pour les applications et les systèmes d’exploitation. Il a été préféré de cloisonner seul l’hyperviseur. Cette disposition donne le schéma suivant :

Rings64bit

Par la suite, AMD et Intel se sont rapidement rendus compte de l’importance que commençait à prendre la virtualisation. Ils ont donc décidé d’inclure dans leurs processeurs des instructions de virtualisation facilitant les opérations liées à cette technique. Ces extensions ont rendu possible la virtualisation matérielle assistée comme je l’ai évoqué précédemment. En même temps, il a été ajouté un anneau « -1 » qui permet à la paravirtualisation d’éviter la mutualisation de l’anneau 3. Ceci a permis de revenir à une disposition plus propre des composants applicatifs parmi les anneaux de protection système. Le schéma ci-dessous illustre la nouvelle disposition.

Rings64bitImproved

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.