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

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.