Étiquette : Réseau

Les pépites d’OpenSolaris : le projet Crossbow

Antoine 2 commentaires

Cette semaine de vacances me permet de faire une petite pause dans la préparation du réseau de l’Utt Arena. Ce billet ne traitera donc pas de cet événement mais d’un autre sujet que je n’ai pas évoqué depuis quelques temps : OpenSolaris. J’ai eu l’occasion de passer pas mal de temps à faire de l’administration réseau sous cet OS et j’y ai découvert des fonctionnalités pour le moins impressionnantes.

Avant de commencer, il est nécessaire de balayer toutes les éventuelles rumeurs quant à une éventuelle disparition d’OpenSolaris suite au rachat par Oracle. De nombreux médias dits « spécialisés » ont publié des informations très largement fausses par rapport aux conséquences du rachat ou ont très largement oublié certains faits. Si vous souhaitez un article relativement neutre sur le sujet, je vous conseille le blog c0t0d0s0.org.

Le projet Crossbow est un sous-projet lié à la distribution OpenSolaris qui a été intégré à la version 2009.06. L’objectif de ce projet était d’adapter la pile TCP/IP à la virtualisation et d’y ajouter de nombreuses fonctionnalités. Je m’intéresserais plus particulièrement aux outils de gestion de bande passante.

La gestion de bande passante ou QoS est une fonctionnalité bien ancrée dans les équipements réseaux. L’objectif de cette technique est de réguler les flux réseau afin de permettre un partage équitable ou bien une limite définie. La mise en place de cette fonctionnalité est particulièrement compliquée et obscure sous Linux. La documentation, particulièrement nécessaire étant donnée la complexité des outils, est difficile à trouver.

OpenSolaris propose un première utilitaire permettant de différencier les différents flux réseaux selon des critères de niveau 3 et 4 : flowadm. Vous allez pouvoir créer un « flow » selon différents critères que vous choisirez. Vous allez ensuite pouvoir attribuer différentes caractéristiques à ce flux. Par exemple, vous pouvez lui donner un ou bien une priorité, voire même une limite de bande passante. L’incroyable avantage de cet outil est la simplicité avec laquelle il est possible de l’utiliser. En une commande, vous arrivez à créer un flux, lui donner une priorité et lui appliquer une limite de bande passante. En voici un exemple :

flowadm add-flow -l bge0 -a transport=UDP -p maxbw=100M, priority=low limit-udp-1

La page de man de flowadm est particulièrement claire et propose de nombreux exemples dont celui ci-dessus. Une seule commande pour faire tout ca, je trouve ca plutôt exceptionnel. La limite minimale de bande passante que vous pouvez attribuer est fonction du MTU. Dans le cas d’un MTU Ethernet classique, il s’agit de 1,2Mbps.

Une autre fonctionnalité très intéressante est la possibilité d’effectuer de « l’accounting » sur les différents flows que vous avez créé. Vous pourriez par exemple avoir envie de connaitre la quantité de données échangées pour chaque flux. OpenSolaris vous propose ceci ainsi que la possibilité de voir la quantité de données échanges par intervalle de temps. Pour cela, vous pourrez utiliser l’utilitaire acctadm. Cet utilitaire vous permet d’activer l’accounting au niveau de votre système et la commande flowadm vous permettra d’en visualiser le résultat.

Ce billet effectue un tour d’horizon rapide de ce que peut proposer le projet Crossbow en termes de gestion de bande passante réseau. OpenSolaris a clairement une grande avance sur Linux sur ce point bien que ce dernier en soit capable, mais clairement pas avec autant de simplicité.

Architecture réseau d’une LAN Party : Configuration des ASA

Antoine 6 commentaires

Ce billet fait suite au précédent qui avait eu pour objectif de définir le contexte de filtrage IP que nous souhaitons mettre en place. Aujourd’hui, nous allons faire un tour de vue du fonctionnement de nos équipements de sécurité et de routage : les Cisco ASA 5510.

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.

Architecture réseau d’une LAN Party : Filtrage

Antoine 2 commentaires

Ce billet continue la série de billets traitant de l’architecture d’une LAN Party. Après avoir présenté la topologie IP de notre réseau, nous allons nous intéresser au filtrage IP.

Avant de commencer à traiter ce sujet, je vais faire un petit point d’avancement sur la préparation du réseau. Nous avons passé 2 soirées à configurer les équipements Cisco et nous avons réussi à créer la topologie IP évoqué au billet précédent en 2 heures. Ce résultat est relativement satisfaisant et a été rendu possible par la préparation des configurations à l’avance. La quantité de VLAN ne nous a pas posé de problème particulier car la configuration des équipements Cisco est claire à ce niveau. Il nous reste juste une petite problématique au niveau de la communication entre deux interfaces du même ASA.

Le filtrage IP est une composante nécessaire de notre configuration réseau car les ASA refusent par défaut le trafic réseau. Dans le cadre d’une LAN, nous pouvons dissocier deux périodes : les périodes de tournoi et les périodes sans tournoi. Nous avons décidé d’adapter la configuration réseau en fonction de chaque période.

Le filtrage IP hors tournoi sera le plus permissif possible. Il n’y a aucun intérêt à restreindre les flux émanant des tables. Nous imposerons éventuellement une limite de bande passante au niveau des flux sortant sur Internet afin d’éviter la saturation trop rapide du lien. Ce niveau de filtrage nous permettra de tester notre configuration réseau sans se soucier des ACL.

Le filtrage IP pendant les tournois sera, au contraire, le plus restrictif possible. L’objectif est de limiter les flux au minimum nécessaire pour les jeux. La présence de flux parasites serait susceptibles d’impacter négativement la latence des flux de jeux causant ainsi le mécontentement des joueurs.

Au final, le filtrage IP s’adaptera en fonction des conditions de la LAN. Ceci se concrétisera par deux jeux d’ACL que nous appliquerons aux interfaces en fonction du filtrage souhaité.

Architecture réseau d’une LAN Party : Conception

Antoine 4 commentaires

Ce billet fait suite au précédent qui avait eu pour objectif de définir le contexte d’un réseau d’une LAN et de présenter le projet. Aujourd’hui, nous allons définir l’architecture IP et L2 de notre LAN.

Avant de commencer, je souhaite faire un petit point d’avancement. La préparation de l’Utt Arena a commencé quelque peu en retard au niveau du réseau pour diverses raisons. Les choses avancent donc très vite et je vais essayer de vous faire partager notre avancement sur ce blog du mieux possible. J’approfondirais plus ou moins les sujets en fonction du temps que j’ai à ma disposition.

Je pense que l’architecture d’un réseau se doit d’être la plus simple possible et la plus logique possible. Si un réseau est simplement compréhensible par un humain, il sera plus facile à gérer et les sources d’erreur seront réduites. La conception de l’architecture est une phase exceptionnellement critique sur laquelle repose tout le reste.

L’objectif de notre réseau est le contrôle des flux et la l’optimisation de la latence. Ces deux objectifs sont quelque peu contradictoires car le contrôle des flux implique l’ajout d’intermédiaires de filtrage et de routage. Nous avons essayé de concilier au mieux ces deux objectifs.

Nous avons créé un VLAN par switch de table ce qui correspond à 20 joueurs pour les tournois CS et CSS. Ces deux tournois sont, de loin, les plus problématiques en terme d’utilisation réseau. Ceci nous fait donc 8 VLAN pour CS et 4 VLAN pour CSS. Pour les tournois TrackMania et Warcraft III, nous avons choisi de faire un VLAN par tournoi. Les joueurs Warcraft III jouent entre eux sans passer par un serveur, il est donc plus simple de les placer dans un VLAN dédié.

Tous les VLAN contenant les joueurs seront routés par un ASA. Nous avons ensuite réparti les VLAN équitablement parmi les ASA.

Ensuite, nous devons interconnecter les ASA entre eux. Nous avons choisi le protocole de routage OSPF car il s’agit d’un protocole simple et efficace. La logique traditionnelle voudrait que nous insérions un routeur central afin de router les flux des 4 ASA. Etant donné que notre objectif est la latence, nous avons choisi de ne pas mettre ce routeur. Les ASA seront donc tous interconnectés par le même réseau IP. OSPF est parfaitement capable de gérer cette configuration en passant par l’élection d’un DR (Designated Router).

Nous avons ensuite ajouté deux routeurs standards afin de router les flux des serveurs et des administrateurs. Ces routeurs participeront également à l’OSPF avec les ASA.

Et pour finir la tache la plus importante, le nommage des équipements. Inutile mais tellement indispensable et amusant. Nous avons choisi des noms de volcans pour les ASA et des noms de montagne pour les routeurs. Les ASA s’appelleront ainsi Etna, Fuji, Kilauea et Pinatubo et les routeurs Everest et K2.

Cliquez sur l’image pour l’agrandir.

Au final, nous obtenons un schéma relativement effrayant. Ce dernier nous a permis de nous rendre compte de la taille du réseau que nous avons projeté de mettre en place. La difficulté est, honnêtement, un facteur très motivant. Cette réflexion a été faite avec toute l’équipe réseau et avec le retour de personnes extérieures ce qui a permis de dynamiser la réflexion.

Dans les prochains épisodes : la spécificité de la configuration des ASA et un rebondissement inattendu ! Quel suspens !

Architecture réseau d’une LAN Party : Introduction

Antoine 6 commentaires

J’avoues avoir un peu de mal à poster des billets régulièrement en ce moment. Cela s’explique en partie par une petite baisse de motivation pour le faire mais aussi la reprise des cours qui sont un peu plus nombreux que prévus.

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.

Livre sur la sécurité informatique : Menaces sur le réseau

Antoine 2 commentaires

Cela faisait quelques temps que je ne vous avais pas recommandé de livre. La dernière fois remonte tout de même à Octobre avec le livre sur Xen. Cette fois-ci, je ne vous recommanderais pas un livre parlant de Xen ou même de virtualisation, mais plutôt de sécurité informatique.

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.