Antoine Benkemoun

15 Mar, 2010

Architecture réseau d’une LAN Party : Introduction

Posté par Antoine dans la catégorie Libre|Réseau|Sécurité

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.

6 Commentaires to "Architecture réseau d’une LAN Party : Introduction"

1 | Edouard

mars 16th, 2010 at 8 h 30 min

Avatar

Intéressant comme sujet, j’ai hâte de voir la suite !

2 | Zaxe

mars 16th, 2010 at 19 h 52 min

Avatar

Étant moi même organisateur de LAN (Spirit-Lan) je vais surveillé cette architecture de LAN.

Je dois avoué, que j’ai des doutes sur l’intérêt de cette solution pour un réseau qui dure 3 jours. J’ai déjà vu des structures s’amuser avec les Vlans et faire machine arrière.

Je présume que tu vas « couper » ton réseau en fonction des différents jeux présent en tournois et router le reste entre eux. Car tes petit gars de CS risque de ne pas apprécier ;).
Après je n’est pas suffisamment recul, mais tes Cisco ASA 5510 gère 75 Mbps en IPS. Grossièrement, à la louche, ca devrait passer sans problème. Vivement ton retour d’expérience.

De mon coté, coté monitoring tout ce fait directement sur les switch en SNMP et sur le routeur Sonicwall pour la sortie WAN. Le routeur est équipé d’une inspection dynamique des paquets et d’un antivirus. Déjà ca me permet de repérer le plus gros.

Ensuite dans une LAN, le partage de fichier fait partie (heureusement ou malheureusement) intégrante de ces événements. La solution envisageable est la mise en place d’une sonde directement sur le switch de tête dont un port est configuré en mirroring. A partir de la, tu peux remonté jusqu’au switch de table, le numéro de port et remonté le câble réseau pour trouver le fautif.
Certes, c’est chiant pour les admin.

3 | Antoine

mars 16th, 2010 at 23 h 32 min

Avatar

Bonsoir,
L’idée est effectivement de cloisonner mon réseau en plusieurs VLAN. Je détaillerais tout ca plus en détail mais j’ai déjà un paquet d’idées. Nous avons également prévu de faire du LLQ.
En ce qui concerne l’IPS ASA, je suis très déçu, il faut quasiment rien ce truc. Juste des protocoles standards type HTTP, SMTP, POP, IMAP et FTP … Ca casse pas trois pattes à un canard.
Nous allons résoudre la question du partage de fichier par des ACL vite fait bien fait. Nous avons prévu plusieurs niveau de filtrage (tournoi/non tournoi) que nous appliquerons en fonction des situation. Les ACL c’est mieux que de l’IDS passif, ca bloque tout.
On a commencé ce soir à jouer avec les ASA et on va en chier, mais c’est ca qui est rigolo !

4 | Souhayel

mars 17th, 2010 at 13 h 54 min

Avatar

Zaxe, j’ai lu ton commentaire et je comprends pas très bien comment tu peux remonter au switch de table sauf si tu fais du port mirroring sur chaque port du switch de tête relié à un switch de table?

Merci

5 | Zaxe

mars 17th, 2010 at 20 h 42 min

Avatar

La solution est de regarder uniquement sur le switch tête. Les switch de table ne pose pas de problème majeur si des échanges sont effectués.
Le facteur limitant est la vitesse du lien entre les switch de table et le switch de tête. Je suppose que les switch de table sont 10/100 avec un port d’uplink en 1000 et que le switch de tête est en 1000. C’est la configuration la plus courante, mais même si le réseau est intégralement en Giga mon raisonnement est le même.
.
Les switch de table ne subissent pas de goulot d’étranglement lors d’échange par des utilisateurs connecté sur le même switch. Le font de panier va encaisser sans problème. Alors que sur l’uplink, on ce retrouve avec le goulot d’étranglementlors des requêtes remontant sur le switch de tête (et inversement). D’où le fait de ne faire que du port mirroring sur le switch de tête.
Ca ne sert a rien de récupérer des informations qui ne sont pas utiles et qui vont encombrer le diagnostique.
.
Une fois que tu as repéré des échanges pouvant ralentir le réseau, on remonte jusqu’au poste fautif via les tables arp.
Sur le switch de tête, tu sais qu’elle est la Mac Adress et sur quel port elle est associé. Sur ce port, tu as de connecté ton switch de table. Sur ce switch de table, tu recherche la Mac Adress dans la table ARP de ce switch qui va te donner le port associé. C’est lourd, mais ca fonctionne.
.

.

Après, si vraiment on désire bloquer tous les protocoles non utiles, il reste les firewall en mode transparent entre le swicht de tête et chaque switch de table.C’est la méthode la plus efficace et ca fait beaucoup de matériel pour surveiller/contrôler le réseau d’une LAN et même d’une entreprise.

6 | Ph1

avril 24th, 2010 at 15 h 47 min

Avatar

Saloute,

Zaxe, ou alors découper en vlans comme le dit antoine avec un Vlan par switch et jouer sur du filtrage intervlan avec un routeur du type netasq :p.
Ainsi, les joueurs téléchargent entre eux sur leur switch s’ils le souhaitent et ne peuvent D/L chez ceux en dehors de leur VLAN.
On peut imaginer que les règles de filtrage ne soient effectives que pendant les phases de tournois ^^.

ça reste chiant à préparer xD.

@+

Ajoutez votre commentaire

A propos de ce blog

Ce blog a pour objectif de partager des informations avec tous les internautes. Comme indiqué dans le titre, je traiterais de différrents sujets gravitant autour de la sécurité informatique, de la virtualisation, de la l'administration système et du réseau.