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.

Souhaitant mieux comprendre ce domaine, je suis parti à la quête d’un livre. De nombreux livres en cryptographie ne sont clairement pas tournés vers les informaticiens mais vers le mathématiciens. Un tel niveau de compréhension n’est pas forcément nécessaire. « Cryptographie en pratique » est un ouvrage adapté à notre situation. Un niveau lycée en mathématiques est demandé pour les explications les plus compliquées ainsi qu’un peu de patience et de relecture pour certains passages.

Ce livre a pour but d’effectuer un tour d’horizon des différentes techniques de chiffrement utilisées aujourd’hui et leurs applications dans le monde réel. Ainsi, vous pourrez comprendre ce qu’est un MAC ou bien comment fonctionne AES. Les auteurs, Bruce Schenier et Nils Ferguson, sont de réelles pointures dans la matière et distillent les retours d’expérience à travers cet ouvrage.

Une partie du contenu de ce livre ne doit plus être tout à fait à jour car il date de 2002 mais une grande partie est clairement atemporel.

Au final, ce livre a été un plaisir à lire et m’a permis de mieux comprendre le fonctionnement et les enjeux de la cryptographie. Je vous le recommande très chaleureusement.

La méthode la plus simple consiste à utiliser les outils easy-rsa en ligne de commande. Ces outils simplifient réellement la tâche par rapport à l’utilisation directe d’OpenSSL. Le problème avec l’utilisation de ces outils est la nécessité d’interagir avec le terminal. Cet outil va vous demander bon nombre de renseignements tels que le pays, la ville, l’adresse email, etc. Cette interaction rend compliquée la création par lots de certificats.

Une méthode plus compliquée, mais plus efficace, consiste à adapter les scripts easy-rsa afin de rendre leur utilisation plus linéaire et non interactive afin qu’un script puisse les exécuter. De plus, j’ai souhaité donner la possibilité de spécifier la durée de validité du certificat au cas par cas, ce qui n’est pas possible par défaut.

Le premier script, build-key-batch, permet de créer une clé en spécifiant une durée de validité. Il n’y a qu’une toute petite modification qui permet de récupérer la durée de validité passée en argument.

#!/bin/sh

if test $# -ne 2; then
     echo « usage: build-key-batch <name> <duree> »;
     exit 1
fi

if test $KEY_DIR; then
     cd $KEY_DIR && \
     openssl req -days $2 -nodes -new -keyout $1.key -out $1.csr -batch -config $KEY_CONFIG && \
     openssl ca -days $2 -out $1.crt -in $1.csr -batch -config $KEY_CONFIG && \
     chmod 0600 $1.key
else
     echo you must define KEY_DIR
fi

Par défaut, easy-rsa nécessite d’exécuter le fichier vars dont le rôle est d’exporter un certain nombre de variables d’environnement utilisées par les scripts de génération de clé. Cela ne me convenait pas car je souhaitais exécuter un seul fichier contenant toutes les informations dont je pouvais avoir besoin. J’ai donc créé un script nommé build-batch qui contient toutes les options.

#!/bin/sh
if test $# -ne 2; then
     echo « usage: batch-build <name> <duree> »;
     exit 1
else
     # Definition des variables
     export D=`pwd`
     export KEY_CONFIG=$D/openssl.cnf
     export KEY_DIR=$D/keys
     export KEY_SIZE=1024
     export KEY_COUNTRY=FR
     export KEY_PROVINCE=XX
     export KEY_CITY=Paris
     export KEY_ORG= »Keeyyyy »
     export KEY_EMAIL= »$1″
     export KEY_CNAME=$1
     ./build-key-batch $1 $2
fi

Ce script nécessite une petite modification du fichier openssl.cnf présent dans le dossier easy-rsa qui est la suivante :

commonName = Common Name (eg, your name or your server\’s hostname)
commonName_max = 64
++ commonName_default = $ENV::KEY_CNAME

Le script a exécuter afin de générer un certificat est donc build-batch suivi de deux arguments qui sont le nom du certificat et la durée de validité. Vous pourrez ainsi générer des certificats pour OpenVPN simplement et efficacement sans nécessiter une intervention humaine.

Source : insights

Avant de rentrer dans le vif du sujet, arrêtons-nous pour faire un petit point d’avancement. Nous commençons à avoir des configurations de base relativement solides qui nous permettent de déployer la topologie IP du réseau à chaque session de travail. Le montage de cette topologie ne pose désormais plus de problème particulier. Nous avons réussi à résoudre le problème de la communication entre deux interfaces d’un même ASA. La résolution de ce problème nous a permis de simplifier grandement nos configurations en supprimant toutes les identités NAT des interfaces à security-level 100, soit toutes nos interfaces internes. Je suis content de notre avancement et nous devrions aboutir sur une préparation satisfaisante.

Les ASA sont la gamme d’équipements de sécurité Cisco orientés vers l’entreprise. J’emplois le terme d’équipement de sécurité et non de pare-feu car cette terminologie est bien plus proche de la réalité. Les fonctionnalités d’un ASA dépassent très largement celles de filtrage protocolaire IP, TCP et UDP. Je vous laisse consulter la liste de fonctionnalités sur le site de Cisco. Nous avons également une carte SSM-AIP pour chaque ASA permettant de faire de l’IPS ce que nous utiliserons pendant l’événement si nous nous ennuyons (sait-on jamais).

Nous avons 4 équipements Cisco ASA 5510 à notre disposition. La version logicielle associée est la version « Base » contrairement à son équivalent haut de gamme, « Security Plus ». La différence entre ces deux versions est réellement énorme. La version « Security Plus » permet de transformer deux interfaces 10/100 en interfaces Gigabit, de débloquer l’interface 3 et d’utiliser le port de « Management » en tant qu’interface de données.

La configuration des ASA est légèrement différente de celle de routeurs Cisco classiques. Cette différence est liée au fait que les ASA ne sont pas basés sur un IOS mais un « Security Appliance OS ». Il y a de nombreuses similarités mais suffisamment de différences pour devoir se documenter spécifiquement.

Je ne vais pas pouvoir détailler toute la configuration des Cisco ASA dans ce billet car il ferait de très nombreuses pages. Je vais cependant relever les points clés qui nous ont posé problème.

Tout d’abord, les ASA sont faits pour faire du NAT entre toutes les interfaces par défaut. Ceci vient de leur héritage historique vis-à-vis des PIX. Ce comportement induit la nécessité d’effectuer de très nombreuses règles de NAT. Il est, heureusement, possible de désactiver ce comportement grâce à la commande « no nat-control « . Une fois le nat-control désactivé, il sera possible de router en direct entre les interfaces tant qu’on effectue une descente dans les security-level. Il sera nécessaire de faire une petite règle de NAT afin de remonter les security-level. Il est cependant tout à fait possible d’effectuer une règle de NAT qui ne modifie aucunement les adresses IP ni les ports afin que l’ASA se comporte comme un routeur.

Ensuite, les ASA considèrent par défaut que du trafic entre deux interfaces de même security-level effectue une montée de security-level. Ce comportement implique la création de nouvelles règles de NAT. Afin d’éviter ce comportement et de minimiser les lignes de configuration, il est possible d’utiliser la commande « same-security-traffic permit inter-interface « . Ainsi, vous simplifiez votre configuration ce qui est très intéressant.

Je mets à votre disposition la configuration de l’ASA nommé Fuji afin que vous puissiez y jeter un regard plus approfondi que mes explications assez superficielles. Il manque les ACL de filtrage en mode tournoi car nous ne les avons pas encore intégrées ainsi que le paramétrage avancé de l’OSPF.

Un autre projet qui va me prendre beaucoup de temps est l’Utt Arena. Mais qu’est ce que l’Utt Arena me diriez-vous ? Il s’agit d’une LAN Party ou, pour faire plus « marketing », un tournoi de jeux vidéo. Ce n’est pas la première fois que je m’investis dans ce projet car j’en avais été président en 2007 et 2008. Depuis, j’ai essentiellement aidé occasionnellement. Pour l’édition 2010, je me suis proposé avec l’aide d’un ami et d’un « nouveau » pour mettre en place et gérer la partie réseau de cette LAN.

Une LAN est un événement d’envergure dans lequel les joueurs ramènent chacun leur ordinateur. Le principal problème provient de ce fait. Il serait possible de croire que les joueurs ont des machines « de course » avec une installation (Windows, forcément) propre. La réalité est tout autre. Nous retrouvons les « versions » les plus exotiques de Windows remplies jusqu’aux oreilles de malware et d’applications non recommandables.

Lors des précédentes éditions, nous avons choisi la simplicité par manque de moyens matériels et humains. Tous les joueurs étaient disposés sur un même LAN (au sens IP du terme) avec un DHCP pour leur allouer des adresses IP automatiquement. L’inconvénient est que tous les ordinateurs pouvaient communiquer sans restriction. Dans de telles conditions, les partages de films interdits aux mineurs et la prolifération des malwares en tous genre sont optimaux.

De plus, il était quasiment impossible d’avoir une visibilité quelconque sur les différents flux échangés ainsi qu’une évaluation de la latence. Ah la latence, parlons-en. Les participants à une LAN ne jurent que par elle. Au dessus de 10 ms affichées par le jeu Counter-Strike, le réseau est considéré trop lent. Bien que des astuces soient possibles au niveau des serveurs de jeu afin d’optimiser l’affichage de cette latence, l’optimisation du réseau est primordiale.

Cette année, nous avons réussi à mettre la main sur une batterie d’équipements de sécurité robustes. Nous aurons à notre disposition 4 firewalls Cisco ASA 5510 ainsi que quelques routeurs Cisco 2800 Series. L’ajout d’intermédiaires de communication au niveau IP induira inéluctablement une latence supplémentaire. Cela nous permettra cependant de pouvoir réellement maitriser notre réseau et de bénéficier des fonctionnalités de QoS du Modular Policy Framework Cisco. Nous espérons sincèrement que cet ajout de latence sera minime au regard des avantages fournis par les fonctionnalités de ces équipements.

Ce billet est le premier d’une série de billets ayant pour objectif de détailler le processus de mise en place de cette architecture ainsi que des différents outils (open source, bien sur) d’évaluation des performances réseau. Elle sera clôturée par un retour d’expérience suite à l’événement qui aura lieu du 16 au 18 Avril. En attendant, je retourne éplucher les différentes documentations des ASA.

J’ai pu emprunter ce livre deux semaines à la Bibliothèque des Sciences et de l’Industrie située à l’intérieur de la Cité des Sciences. Je me suis tourné vers cette bibliothèque car il s’agissait de la plus proche de mon lieu de travail avant la reprise des cours. J’y ai cependant trouvé un large choix de livre récents traitant de nombreux sujets informatiques. J’avais plutôt été habitué aux livres poussiéreux des bibliothèques classiques. Je vous recommande donc ce lieu si vous passez dans le coin !

« Menaces sur le réseau » est un ouvrage traitant de la sécurité informatique au sens très large. Il a été écrit par un chercheur en sécurité informatique polonais qui explique les différents concepts avec une pédagogie exceptionnelle. Ce livre reprend rapidement les bases théoriques nécessaires à la compréhension des éléments techniques et vous explique différentes techniques d’attaques. Il est donc à lire si vous avez certaines bases en systèmes d’exploitation et en réseaux IP.

Ce livre permet de comprendre plus concrètement le monde de la sécurité informatique. Un exemple est l’explication du fingerprinting de systèmes d’exploitation dont l’auteur semble particulièrement friant. Vous comprendez quelles sont les traces laissées par les systèmes d’exploitation dans tous les paquets IP qu’ils émettent. Un autre exemple est le fingerprinting d’OS en se basant uniquement sur les ID des paquets IP, ce qui est pour le moins créatif mais surtout impressionnant. Grâce à une analyse statique graphique, l’auteur arrive à démontrer la possibilité de cette technique, intimement liée au fait que les ID ne sont pas générés tout à fait aléatoirement.

Au final, ce livre est à lire absolument pour tous ceux qui souhaitent s’intéresser à la sécurité dans le domaine des systèmes d’exploitation et des réseaux et qui ont quelques bases dans ces domaines. Pour ceux qui souhaitent s’intéresser aux aspects « management » de la sécurité, passez votre chemin.

Les dangers liés au cloud computing sont la conséquence directe de la dématérialisation des infrastructures physiques.

Tout d’abord, la première problématique est la localisation des données. L’abstraction des infrastructures physiques rend la localisation de données spécifiques significativement plus compliquée. Cette incertitude induit une sécurité pas forcément amoindrie mais certainement considérablement complexifiée.

Cette première problématique est évidente dans le cas des clouds publics ou privés-publics. Le client des infrastructures de cloud computing accorde une confiance totale aux prestataires en lui livrant toutes ses données. Bien que la plupart des argumentaires commerciaux mettent en avant une sécurité des données et, le plus souvent, un chiffrement, il est impossible de vérifier cela. Le client devient spectateur de la sécurisation de ces données.

Nous pouvons faire une exception à cette problématique dans le cas de clouds privés-publics. Ce cloisonnement reste tout à fait relatif. Ce cloisonnement peut être, dans le cas d’infrastructures « bas de gamme » seulement un mécanisme réseau tel que les VLAN. Ce mécanisme peut difficilement être considéré en tant que mécanisme de cloisonnement de données efficace.

Dans le cas d’infrastructures « haut de gamme », nous pouvons imaginer une architecture de type « cloud computing » exclusive à chaque client. Cette alternative se place dans le haut de gamme par le coût que cela engendre. Ce type d’offre permettrait, au passage, une plus grande flexibilité dans l’architecture à tous les niveaux.

Au final, la sécurité des données est une réelle problématique du cloud computing. Nous nous intéresserons plus tard aux problématiques d’interopérabilité des plateformes.

Pour rappel, OpenVPN est une application qui permet de créer des tunnels VPN chiffrés afin d’y faire passser du trafic IP. Cette application est relativement simple à utiliser une fois qu’on a réussi à comprendre rapidement son fonctionnement. Je vous en avais déjà parlé à travers l’article sur Viscosity, client VPN pour MacOS. Si vous êtes intéressés par un tutoriel d’installation sous Linux, je vous renverrais vers l’excellent tutoriel écrit par Smurf.

Pré-requis

Afin de pouvoir installer OpenVPN sur OpenSolaris, il va vous falloir une installation fonctionnelle d’OpenSolaris. Logique, non ? Nous allons ensuite travailler avec les packages fournis par Blastwave. Il s’agit d’un dépot de paquets spécifiques de manière similaire au dépots Sun. L’avantage de Blastwave est que les paquets sont plus nombreux et plus récents. Le nom des paquets Blastwave commencent par CSW au lieu de SUNW pour les paquets Sun. Afin de pouvoir installer facilement des paquets Blastwave, il est nécessaire de récupérer et installer l’utilitaire d’installation pkgutil (sorte d’équivalent à apt-get).

# wget ftp://ftp.belnet.be/packages/blastwave.org/pkgutil_1.6.1_i386.pkg

# pkgadd -d pkgutil_1.6.1_i386.pkg

Une fois cette utilitaire installé, nous allons pouvoir installer le reste beaucoup plus simplement.

Installation

Tout d’abord, nous allons devoir récupérer et installer les modules tun et tap nécessaires pour le fonctionnement d’OpenVPN. Une fois que ces modules seront installés, nous allons pouvoir nous occuper d’OpenVPN. De manière similaire à apt-get, la récupération des binaires et leur installation est automatique.

# /opt/csw/bin/pkgutil -i tun tap
# /opt/csw/bin/pkgutil -i openvpn

L’installation de tous ces paquets se fait toute seule. Il sera juste peut être nécessaire de confirmer l’installation en tapant un simple « y ».

Génération des certificats

Une fois l’installation initiale des paquets terminée, nous allons nous attaquer à la génération des certificats. Nous allons tout d’abord créer le certificat racine de notre serveur OpenVPN. Le certificat racine est le certificat d’origine qui servira à signer tous les certifications délégués aux utilisateurs de notre concentrateur VPN.

# cd /etc/csw/openvpn/easy-rsa
# source vars
NOTE: when you run ./clean-all, I will be doing a rm -rf on /etc/csw/openvpn/easy-rsa/keys
# ./clean-all
# ./build-ca
Generating a 1024 bit RSA private key
.++++++
………..++++++
writing new private key to ‘ca.key’

Un certain nombre de questions vous seront ensuite posées. Les réponses à ces questions permettront de pouvoir identifier plus clairement votre certificat racine. Rassurez-vous, il n’y a donc pas de mauvaise réponse. Une fois que vous aurez fini, vous remarquerez que deux nouveaux fichiers ont été créés : ca.crt et ca.key. Le fichier ca.key est à garder précieusement car c’est ce dernier qui permet de signer et de créer de nouveaux certificats donnant accès à votre concentrateur VPN. Nous allons ensuite créer le jeu de clés du serveur OpenVPN.

# ./build-key-server server
Generating a 1024 bit RSA private key
………………………………………………++++++
………………..++++++
writing new private key to ’server.key’

Une fois le certificat du serveur créé, vous retrouverez les fichiers server.key et server.crt. Nous allons ensuite pouvoir créer les certificats de nos utilisateurs. Des informations vous seront également demandées sur l’utilisateur pour la création de certificat. Ces informations permettent d’identifier vos utilisateurs, vous avez donc tout intérêt à les remplir précisément.

# ./build-key antoine
# ./build-key jeanmarc

Afin d’achever la génération des certificats, nous allons devoir créer le paramètre de Diffie-Hellman. La génération peut prendre du temps surtout sur un processeur peu occupé.

/etc/csw/openvpn/easy-rsa# ./build-dh
Generating DH parameters, 1024 bit long safe prime, generator 2
This is going to take a long time

Configuration d’OpenVPN

Tout d’abord, nous allons devoir rendre accessible au service les différents certificats dont il va avoir besoin.

# cd /etc/csw/openvpn
# /etc/csw/openvpn# cp openvpn.conf.CSW openvpn.conf
# /etc/csw/openvpn# ln -s easy-rsa/keys/dh1024.pem
# /etc/csw/openvpn# ln -s easy-rsa/keys/server.crt
# /etc/csw/openvpn# ln -s easy-rsa/keys/server.key
# /etc/csw/openvpn# ln -s easy-rsa/keys/ca.crt

Il est nécessaire ensuite de renseigner les différentes informations dans le fichier de configuration d’OpenVPN. Je ne parlerais pas de ce fichier en détail ici car d’autres sites le font déjà et bien mieux que moi. Les lignes importantes sont les suivantes. L’utilisation de TCP pour un VPN est sous-optimal mais permet de contourner une bonne partie des firewalls associé avec le port 443 (HTTPS).

port 443
proto tcp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
server 172.19.0.0 255.255.255.0

Ensuite, vous allez pouvoir tester votre paramétrage en exécutant le service OpenVPN.

# ifconfig tun0 unplumb
# /opt/csw/sbin/openvpn /etc/csw/openvpn/openvpn.conf

L’affichage des logs sera fera directement sur votre écran ce qui vous permettra de diagnostiquer d’éventuelles erreurs de configurations ou de connexion. Et ensuite, pour lancer définitivement le démon :

# ifconfig tun0 unplumb && /etc/init.d/openvpn start

Au final, ce petit tutoriel vous permettra de créer un tunnel OpenVPN afin de pouvoir communiquer avec votre serveur de manière sécurisée. Je ferais un autre billet expliquant les manipulations supplémentaires pour passer toute sa connexion Internet dans ce même VPN. Ce tutoriel est largement inspiré d’un autre tutoriel en anglais.

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.