Problématique

Le besoin initial de cette application est la gestion des règles iptables d’un parc de machines. En tant qu’administrateurs système, nous ne retrouvons régulièrement à gérer des scripts iptables sur divers serveurs. Lorsqu’on gère 5-10 serveurs, la gestion à la main reste acceptable. Cependant, dès que l’on commence à gérer plus de serveurs, ca commence à devenir réellement long et fastidieux. Et qui dit fastidieux dit fort potentiel d’erreurs.

J’ai donc entrepris de créer une application qui permettrait de gérer tout ca de manière un peu plus automatisée. L’application Netfilter Manager est donc née. Le nom est pas tout à fait extraordinaire mais ca représente à peu près ce que ca fait.

Présentation

Netfilter Manager utilise donc une interface en ligne de commande afin de pouvoir gérer un lot d’hôtes et les règles associées. Cette CLI est inspirée quelque peu de la CLI Cisco pour ceux qui ont déjà eu la chance l’occasion de l’utiliser. La licence de l’application est GPLv3. J’avoue ne pas être un expert dans le domaine des licences de logiciel mais c’est une des plus répandues et le peu que j’en connais me convient.

Chaque hôte dispose d’un nom et d’une adresse IP. A la place de l’adresse IP, on peut bien sûr utiliser un nom DNS que le serveur de gestion saura résoudre. L’application ne supporte que pour l’instant Iptables, il n’est donc pas encore possible de sélectionner un type d’hôte mais c’est une fonctionnalité envisageable.

Les règles sont ajoutées hôte par hôte et peuvent être organisées par ligne. Par défaut, les règles que vous ajoutées sont ajoutés à la suite des règles existantes. Il est possible de gérer plus finement l’ordonnancement des règles en utilisant la gestion par ligne. Chaque ligne peut comporter plusieurs règles et les règles seront appliquées dans l’ordre croissant des lignes. Ce comportement est très similaire au mode de fonctionnement des access-list Cisco.

Voici un petit exemple d’utilisation :

Il est également possible de créer des lots de règles grâce à un moteur de template dont l’utilisation est expliquée dans le README. Vous trouverez un exemple de template dans le fichier cobalt.tpl présent dans le répertoire templates.

Une fois que vous avez créé toutes les règles de firewall, vous allez pouvoir les « pousser » vers vos serveurs. Un script contenant les règles est généré en prenant les règles que vous avez spécifié et en ajoutant au début le contenu du fichier start.tpl. Par défaut, ce fichier contient des règles permettant de supprimer les règles iptables actuellement utilisées.

Pour en savoir plus sur l’utilisation de l’application, la commande help devrait pour vous aider. Sinon je vous conseille de lire le README (en anglais pour l’instant). J’espère que les explications sont claires et vous permettront de réussir à utiliser l’application. Si ce n’est pas le cas, vous pouvez me le faire savoir soit par ce blog soit par le bugtracker de github.

Bonus

En petit bonus, j’ai ajouté la possibilité de créer des règles en utilisant la syntaxe Cisco. Pour l’instant, seuls les règles IP sont supportées mais les règles TCP/UDP devraient également être supportées par la suite. Dans le mode ajout, il faut utiliser la commande access-list. Un page d’aide a été spécifiquement ajouté, vous pouvez y accéder en tapant access-list help. Je ne suis pas sûr que ce soit d’une utilité débordante mais ca m’a bien amusé de le coder.

Code

Tout le code de l’application est disponible sur github. Vous pouvez télécharger la version courante de l’application en cliquant sur ce lien.

Si vous souhaitez contribuer, vous êtes les bienvenus. Tout se passe via le git proposé par github. L’application est faite en Python et j’ai essayé de rendre le code le plus lisible possible. Si vous souhaitez effectuer des remontées de bugs ou me donner votre avis, vous pouvez le faire sur ce blog ou sur github.

En Avril, j’avais écrit un petit billet sur la génération de certificats OpenVPN par lots ce qui est bien pratique lorsqu’on doit en générer une quantité importante. J’ai à nouveau rencontré cette problématique mais dans un contexte légèrement différent. Sous Ubuntu Server 10.04, le jeu d’outils Easy-RSA d’OpenVPN n’utilisent plus OpenSSL directement mais utilisent pkitool qui ne semble être qu’un intermédiaire de simplification.

Du coup, le script donné précédemment n’est plus valable. Il a donc fallu trouver une parade assez simple mais non moins fonctionnelle. La solution adaptée à pkitool ne tient plus qu’en un seul script qui est le suivant.

#! /bin/bash

# Make a certificate/private key pair using a locally generated

# root certificate.

export EASY_RSA= »`pwd` »

export OPENSSL= »openssl »

export PKCS11TOOL= »pkcs11-tool »

export GREP= »grep »

export KEY_CONFIG=`$EASY_RSA/whichopensslcnf $EASY_RSA`

export KEY_DIR= »$EASY_RSA/keys »

export PKCS11_PIN= »dummy »

export KEY_SIZE=1024

export CA_EXPIRE=3650

export KEY_EXPIRE=3650

export KEY_COUNTRY= »FR »

export KEY_PROVINCE= »FR »

export KEY_CITY= »Paris »

export KEY_ORG= »Antoine-Corp »

export KEY_EMAIL= »me@myhost.mydomain »

export KEY_CNAME=$1

export EASY_RSA= »${EASY_RSA:-.} »

« $EASY_RSA/pkitool » $*

Le tour est joué ! Vu que WordPress (ou plutôt de ces modules/thèmes) remplace les quotes par des guillemets impossibles à copier/coller dans un shell, je vous mets à disposition une version en texte brut jusqu’à ce que j’ai réussi à résoudre ce problème assez agaçant.

Au final, ce script devrait vous être utile pour générer rapidement des certifications OpenVPN à la pelle et ainsi vous simplifier la vie.

Dans les billets précédents, l’objectif avait été de proposer quelques ajustements vis à vis de la conférence sur la sécurité de la virtualisation lors de la Nuit de Hack. Ces articles s’étaient donc voulus plutôt rassurants cependant il est nécessaire de mitiger ce portrait. Les risques liés à la sécurité de la virtualisation existent bien. Affirmer le contraire serait au mieux une vulgaire erreur.

Nous allons aujourd’hui nous intéresser aux vulnérabilités qui ont déjà été trouvées dans des produits de virtualisation et leurs implications.

Xen

Nous allons premièrement nous intéresser au produit Xen open source. Le produit Citrix est un produit hybride s’inspirant largement du produit open source mais disposant de nombreuses modifications qui dépassent le périmètre de ce dernier. La conception de Xen se veut sécurisée par le biais, notamment, de l’utilisation des différents anneaux de protection système. Son histoire n’est cependant pas exempte de vulnérabilités.

La plus grosse vulnérabilité de Xen date de Septembre 2007. Il s’agissait d’une faille qui permettait à un domU d’exécuter des commandes dans le dom0 lors de l’utilisation de l’outil pygrub. L’outil pygrub permet à un domU de disposer d’un bootloader similaire à celui que l’on peut trouver sur une machine physique classique. Cette faille est extrêmement problématique dans la mesure où le dom0 est un domaine exceptionnellement sensible qui dispose de très nombreuses interactions directes avec le matériel et l’hyperviseur. Vous pourrez trouver plus d’informations sur cette faille sur l’OSVDB.

D’autres vulnérabilités ont été trouvées dans Xen permettant à un domU de sortir de son isolation. La plupart de ces failles nécessitent des conditions très particulières afin d’être exploitables ou ne permettent au mieux qu’un DoS local. La liste des failles est disponible sur l’OSVDB.

VMWare

Nous allons ensuite nous intéresser au produit VMWare. La liste des vulnérabilités pour ce produit est nettement plus longue avec un net pic en 2008. Le plus grand nombre de vulnérabilités s’explique surement en partie par la grande étendue des produits VMWare qui incluent aussi bien l’hyperviseur que tous les outils de gestion associés (Virtual Center, Service Console, …).

Parmi toutes ces vulnérabilités, on en recense 4 qui permettent une violation de l’isolation des machines virtuelles. Ces élévations de privilèges se font à travers les VMWare Tools quant il s’agit de machines virtuelles ou à travers les produits connexes à l’hyperviseurs.

Conclusion

Les produits de virtualisation ne sont clairement pas exempts de vulnérabilités quoi que l’on puisse dire. L’impact d’une vulnérabilité sur une plateforme de virtualisation sera largement plus important par rapport à une architecture classique. Il est cependant nécessaire de nuancer ces propos. De nombreuses mesures sont prises afin d’éviter que ces vulnérabilités puissent avoir un impact quelconque sur le reste de la plateforme. De plus jusqu’à présent, l’impact des failles de sécurité est relativement minime et leur fréquence plutôt faible. Il convient donc de rester vigilant aux évolutions des plateformes de virtualisation en matière de sécurité.

Pour en savoir plus, je vous conseille la présentation de Julien Raeis et Nicolas Collignon à ce sujet. Les deux tableaux récapitulatifs présents dans cet article sont extraits de cette présentation.

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

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é.

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.