Préconisations nomadisme et déploiement de réseaux locaux ... · 3.1. Les bornes sans fil...

1/12/2003 Draft sur 29

Préconisations

nomadisme

et

déploiement

de réseaux locaux sans fil

Universités de l’académie de Grenoble

Version 4.02

Nomadisme et Wifi Universités de Grenoble

Preconisations-wifi-v4.doc 2

1. Préambule _________________________________________________________ 3 2. Participants ________________________________________________________ 3 3. Principes généraux __________________________________________________ 3

3.1. Les bornes sans fil ____________________________________________________ 3 3.2. Vulnérabilités_________________________________________________________ 7

3.2.1. Brouillage__________________________________________________________________ 7 3.2.2. ARP Poisoning______________________________________________________________ 7

3.3. L’identification/authentification/cryptage__________________________________ 7 3.3.1. Le SSID : Service Set Identifier _________________________________________________ 7 3.3.2. Protocole WEP : (Wired Equivalent Privacy) _______________________________________ 8 3.3.3. Filtrage par adresse MAC _____________________________________________________ 8 3.3.4. Solution de type 802.1x/EAP ___________________________________________________ 9 3.3.5. Solution de type 802.11i ______________________________________________________ 9 3.3.6. Solution de type VPN IPSec __________________________________________________ 10 3.3.7. Solution de type SSL ________________________________________________________ 10

4. Solution retenue par les établissements Grenoblois _____________________ 11 4.1. L’infrastructure réseau sans fil : un réseau par Etablissement _______________ 11 4.2. L’identification / authentification : mise en place d’une solution à base de VPN_ 12 4.3. Autres sites _________________________________________________________ 13 4.4. Déploiement des serveurs _____________________________________________ 13

4.4.1. Serveurs radius ____________________________________________________________ 13 4.4.2. Serveurs DHCP ____________________________________________________________ 14 4.4.3. Serveurs HTTP et FTP ______________________________________________________ 14

4.5. Gestion du réseau Wifi ________________________________________________ 14 4.5.1. War driving________________________________________________________________ 14 4.5.2. Maintenance du réseau ______________________________________________________ 14 4.5.3. Sécurité et VPN ____________________________________________________________ 14

5. Les Matériels testés ________________________________________________ 14 5.1. Les points d’accès ___________________________________________________ 14 5.2. Les dispositifs d’identification / authentification / cryptage__________________ 15

5.2.1. Les solutions VPN __________________________________________________________ 15 5.3. Les solutions SSL ____________________________________________________ 16 5.4. Les solutions de type Firewall __________________________________________ 17 5.5. Les commutateurs à la norme 802.3af ___________________________________ 17



1. PREAMBULE

Nous abordons ici la prise en charge du nomadisme par deux aspects qui sont loin de répondre à une problématique générale. Le document a été fait à l’origine par un groupe de travail devant élaborer des préconisations. Le document répond à une demande précise dans un contexte d’utilisation donné : il s’attache à donner un cadre pour le déploiement de réseaux sans fil sur les campus Grenoblois, le but étant également de limiter tout déploiement sauvage sur les campus.

Nous traitons donc de la problématique des points d’accès à base de cette dernière technologie et de la problématique large sur tout ce qui touche la confidentialité à savoir : l’identification, l’authentification et le cryptage.

2. PARTICIPANTS

Ce document a été élaboré à partir des travaux effectués par les différents établissements Grenoblois. Les principaux contributeurs sont :

• Gilles Bruno, Philippe Boucard, Jacques Eudes, Jérôme Le Tanou (Grenoble1). • Lionel Billiet, Vincent Loupien, Pascal Praly et Stephane Rongiere (Grenoble2). • Ramon Alvarez, Henri Naval (Grenoble3). • Eric Jullien, Patrick Petit (Cicg). • Gilles Berger-Sabbatel (LSR – IMAG), Laurent Aublet-Cuveliet (IMAG).

3. PRINCIPES GENERAUX

3.1. Les bornes sans fil Faisons une synthèse rapide des propriétés / contraintes / législation sur la technologie des réseaux sans fil.

Les normes de transmission Les normes 802.11 propres aux réseau Ethernet sans fils sont édictées par l'IEEE (Institute of Electrical and Electronics Engineers). Ils autorisent des débits théoriques maximum de 11 Mbps (802.11b) et 54 Mbps (802.11g validé le 12/06/2003) dans la bande des 2.4Ghz avec des puissances d'émission de 10 à 100 mw selon les canaux. 802.11a opère dans la bande des 5Ghz avec un débit jusqu'à 54 Mbps.



Tableau récapitulatif des normes de transmission 802.11 b 802.11 g 802.11 a Fréquence 2,4Ghz 2,4Ghz 5Ghz Bande de fréquences

2,4-2,4835Ghz 2,4-2,4835Ghz 5,150-5,725Ghz

les débits 11 Mbits/s théorique 54 Mbits/s théorique 54 Mbits/s théoriqueNombre de bandes de fréquences (canaux)

13 13 19

Le nombre de bandes de fréquences sans recouvrement

3 3 8

Compatibilité aucune 802.11 b aucune Les lois de la radio

Débit plus grand = Couverture plus faible Puissance d’émission élevée = Couverture plus grande, mais durée de

vie des batteries plus faible Fréquences radio élevées = Meilleur débit, + sensible aux obstacles

=> couverture plus faible Recommandations Les bornes déployées devront être compatibles avec les normes 802.11b ou 802.11g. Puissances et fréquences (législation en vigueur au 5/11/2003) Ainsi, dans tous les départements métropolitains, qu’il s’agisse d’usage privé ou public, il est désormais possible d'utiliser les fréquences RLAN dans les conditions données dans les tableaux récapitulatifs sur les puissances autorisées pour les réseaux locaux radioélectriques dans la bande 2,4 GHz depuis le 25 juillet 2003.ainsi que dans la bande 5 GHz. Les puissances sont exprimées en PIRE (Puissance Isotrope Rayonnée Equivalente).



Fréquences en MHz Intérieur Extérieur 2400 2454

100 mW

2483,5

100 mW

10 mW

Fréquences en MHz Intérieur Extérieur 5150 5250 200 mW impossible

5350

200 mW avec DFS/TPC ou équivalentou 100mW avec DFS uniquement

impossible

5470 5725

impossible impossible

DFS : dynamique des fréquences Problème de performance il faut savoir que, contrairement aux réseaux LAN Ethernet, la détection des collisions est impossible sur les réseaux sans fil. En effet, pour détecter une collision, une station doit être capable de transmettre et d’écouter en même temps. Or, dans les systèmes radio, il ne peut y avoir transmission et écoute simultanées. Pour gérer les collisions, on utilise donc le protocole CSMA/CA qui tente de les éviter en imposant l'émission d'un accusé de réception systématique pour chaque paquet de données arrivé intact. CSMA/CA permet donc de partager l’accès aux ondes. Cette méthodologie garantit en outre un traitement égalitaire pour tous les terminaux, de sorte que lorsqu'un terminal se connecte à un débit relativement faible, il pénalise tous les autres terminaux. Notons que le protocole CSMA/CA est commun aux trois normes 802.11a, 802.11b et 802.11g, Anomalies de performances des réseaux Wi-Fi : http://drakkar.imag.fr/news/perf.html Recommandations



En ce qui concerne les normes de transmission, les standards 802.11b et 802.11G sont ceux qui répondent au mieux à notre problématique de déploiement sur un campus comportant des lieux intra et extra-muros. Pour la puissance émise par les bornes, il est préférable qu’elle soit réglable et réponde aux normes françaises en vigueur. Voir les recommandations de l’ART : www.art-telecom.fr Le POE 802.3af Avec le standard 802.3af Power Over Ethernet, les commutateurs devraient désormais alimenter en électricité des téléphones IP, des points d'accès (AP) sans fil ou des caméras de vidéosurveillance, le tout via le câblage cuivre existant catégorie 3, 5, 5e ou 6 sur une distance maximale de 100 m. Les applications sont multiples, comme le fait d'utiliser un seul UPS pour protéger les équipements alimentés via les commutateurs 802.3af ou de faciliter l'installation des AP sans fil souvent situés dans des endroits peu pratiques d'accès. Apparemment l'électricité pourrait monter à 48 volts et jusqu'à 12 watts de puissance... (Le paragraphe ci-dessus provient d’un l’article du magazine « Réseaux & Télécoms » mis en ligne le 11/04/2003 par Alain COFFRE) Recommandations

A terme, le point d’accès doit pouvoir être alimenté selon le protocole IEEE 802.3af (Power Over Ethernet). Dans le cas où l’établissement ne dispose pas de commutateurs répondant à cette norme, des dispositifs existent et peuvent être insérés entre le point d’accès et le commutateur pour permettre l’alimentation électrique via la connexion filaire.

Remarque : Dans la norme 802.3af, il est proposé une fonction de déconnexion (DC) permettant de suspendre l’envoi de courant quand il n’y a plus personne en ligne. Apparemment Cisco n’a pas ratifié cette fonction (dixit F. Hadj lors de sa dernière visite) car ce point a été breveté par un cabinet d’assurance pour pouvoir demander des royalties. Cisco invoque cette raison pour proposer sa propre fonction de déconnexion (AC). Celle-ci n’est bien entendu pas (encore ?) normalisée… à suivre.

Cisco n’est donc pas 802.3af, mais les autres constructeurs non plus semble-t-il (cf chapitre sur les équipements ci-dessous)…

Sécurité Recommandations Inclure une fonctionnalité permettant d’interdire les communications entre les clients connectés au point d’accès (fonction "Public Secure Packet Forwarding" chez Cisco, Fonction "Local Bridge Filter" chez Nortel Networks, "Station to station bridging" chez Extreme Networks).



En complément de cette fonctionnalité, prévoir le même type de fonction sur les commutateurs concentrant les bornes (private vlan par exemple, toujours chez Cisco).

3.2. Vulnérabilités

3.2.1. Brouillage

Le 802.11 n’intègre pas de mécanisme de gestion des interférences radio, c'est la raison pour laquelle un signal peut facilement être brouillé par une émission radio ayant une fréquence proche de celle utilisée dans le réseau sans fil.

A l’heure actuelle, il est difficile de se prémunir d’une attaque de type déni de service à l’aide de dispositifs électroniques de brouillage. Surtout en sachant qu’un simple four micro-onde en fonctionnement peut-être suffisant pour perturber un réseau sans fil.

3.2.2. ARP Poisoning

Le réseau sans fil comme tout réseau Ethernet n’est pas insensible aux attaques de type « ARP Poisoning ». Un document sur les attaques ARP dans le cadre d'un réseau sans fil est disponible sur le lien suivant :

http://www.cigitallabs.com/resources/papers/download/arppoison.pdf

3.3. L’identification/authentification/cryptage

3.3.1. Le SSID : Service Set Identifier

Pour se connecter à un point d'accès il est indispensable de connaître l'identifiant du réseau (SSID). Ainsi il peut être recommandé de modifier le SSID et d’interdire son annonce sur le réseau sans fil. Cependant, il faut savoir que cet identifiant peut facilement être retrouvé par une simple écoute et ensuite utilisé. Il est donc illusoire de se baser sur le SSID pour limiter l’accès à un réseau sans fil. Quelques SSID par défaut des constructeurs :

Constructeur SSID par défaut Apple Airport Cisco Aironet tsunami Agere (Lucent) AirWave Linksys linksys Nokia Nokia WLAN Compaq Compaq Cabletron RoamAbout Z-Com ftw-mc-2 Gemtek defaut



Leichu WLAN Lucent Technologies WaveLAN Network D-Link default

3.3.2. Protocole WEP : (Wired Equivalent Privacy)

Le 802.11 intègre un protocole de sécurité au niveau liaison appelé « WEP » (Wired Equivalent Privacy). Le WEP utilise l'algorithme de chiffrement RC4. La clef résultante de l'algorithme RC4 est d'une longueur de 64, 128 ou 256 bits, cette suite d'octets est composée d'un Vecteur d'Initialisation (IV) sur 24 bits et d'une clef sur 40, 104 ou 232 bits dépendante de ce vecteur d'initialisation et de la clef WEP initiale. Cette clef permet de générer un « pseudo aléa » d'une longueur égale à la taille maximale d'une trame. Le chiffrement est effectué par un OU EXCLUSIF (XOR) entre ce « pseudo aléa » et le message transmis décomposé en blocs de longueur identique.

Cependant le processus de génération des clefs décrit dans le protocole présente quelques faiblesses :

• La première vulnérabilité concerne la faible longueur des clefs, certains équipements ne proposant que clefs de 40 bits. Cette faible longueur de clef facilite une attaque par « force brute » et permet d'obtenir la clef « WEP » dans un délai raisonnable.

• La seconde faiblesse de ce protocole a été identifiée par Fluhrer, Mantin et Shamir. En raison de l'implémentation de l'algorithme de chiffrement RC4, ils ont mis en évidence de larges ensembles de clefs dites « faibles ». Plusieurs outils disponibles sur Internet permettent d'obtenir le pseudo aléa généré.

• Afin de contrer cette vulnérabilité, certains composants suppriment ces clefs dites « faibles ». Dans ce cas une simple analyse statistique suffit à découvrir le pseudo aléa généré.

Cette clé de session partagé par toutes les stations est statique, c'est-à-dire que pour

déployer un grand nombre de stations WiFi il est nécessaire de les configurer en utilisant la même clé de session.

3.3.3. Filtrage par adresse MAC

Le filtrage par adresse MAC ne fait pas partie de la norme 802.11 mais c’est une fonction que l’on trouve sur la majorité des équipements réseau Ethernet. Voici son principe

• Chaque dispositif réseau dispose d’une adresse physique unique représentée par 12 chiffres hexadécimaux : l’adresse MAC. Par exemple : 00:20:af:88:09:9f

• On peut donc demander à un point d’accès de limiter les accès à une liste d’adresses connues

• Lourd à mettre en œuvre si on a beaucoup de points d’accès (il faut configurer tout les points d’accès) ou si on a beaucoup de clients potentiels (il faut rentrer toutes



les adresses MAC des clients potentiels). Ce qui en fait une méthode réservée sur des petits réseaux.

• Comme sur n’importe quel réseau Ethernet ce filtrage très facile à contourner, il suffit pour cela de modifier logiciellement l’adresse MAC renvoyée par l’équipement.

o Exemple de changement de l’adresse MAC sous linux : Ifconfig eth0 hw ether 00:20:af:88:09:9f

o SMAC : MAC Address Modifying Utility for Windows 2000 and XP systems http://www.klcconsulting.net/smac/

• Ne résout pas le problème de la confidentialité des échanges.

3.3.4. Solution de type 802.1x/EAP 802.1x : solution permettant d’identifier/authentifier un utilisateur avant son accès physique au réseau (réseau de type 802.1 donc ethernet, token-ring, …). EAP : couplé à 802.1x, permet d’utiliser un serveur d’authentification de type kerberos ou radius pour l’identification/authentification d’un utilisateur. Pour plus d’info, lire : http://www.urec.cnrs.fr/securite/CNRS/vCARS2003/DOCUMENTS/saccavini.pdf Avantages et Inconvénients dans notre contexte

• Authentification avant accès au réseau (mais il faut installer un client 802.1x sur chaque poste),

• Généralisable pour tout accès à un réseau Ethernet, mais pas généralisable pour les nomades « distants » (de type adsl, etc.),

• Sans fonctionnalité de cryptage des échanges utilisateurs, difficile de l’utiliser pour une problématique de type réseaux sans fil.

3.3.5. Solution de type 802.11i La norme 802.11i a pour but d'améliorer la sécurité des transmissions (gestion et distribution des clés, chiffrement et authentification). Cette norme s'appuie sur deux existants intéressants :

• l'AES (Advanced Encryption Standard) qui propose un chiffrement des communications pour les transmissions utilisant les technologies 802.11a, 802.11b et 802.11g.

• le WPA : une sorte de WEP (Wired Equivalent Privacy) amélioré notamment en ce qui concerne l’échange des clefs pour l’identification/authentification.

Avantages et Inconvénients pour nous Apparemment WPA et AES pourraient être un couple intéressant dans un avenir proche mais pas encore mur pour un déploiement généralisé dès à présent (pas vu d’offres compatibles 802.11i sur les bornes). D’autre part, là également impossible d’intégrer les



« nomades » distants autres que ceux des réseaux sans fil.

3.3.6. Solution de type VPN IPSec Les solutions de types VPN permettent d’identifier/authentifier, d’affecter une adresse IP et de crypter les communications. Les boîtiers VPN peuvent être couplés à un serveur d’identification/authentification (kerberos, radius, LDAP et TACACS+). Ils offrent divers formats de cryptage DES, 3DES, AES, CAST, et Blowfish. Suivant le constructeur et les performances du boîtier, l’encryptage peut être fait sur un nombre de bits plus important. Le protocole IPSec implémenté dans les boîtiers VPN offre la possibilité de travailler aussi bien en UDP qu’en TCP au niveau de la couche transport. Avantages et Inconvénients pour nous Le cryptage et l’authentification ne sont pas faits au niveau des bornes mais à un niveau plus élevé. Tant que l’on n’est pas connecté sur le boîtier VPN, dans le cadre d’un réseau sans fil on peut circuler librement sur le réseau local sauf si l’on s’appuie sur deux fonctionnalités propriétaires mais existant chez plusieurs fournisseurs (cf matériels testés) :

• La capacité des bornes à empêcher tout dialogue entre les différents utilisateurs des bornes.

• La capacité des commutateurs concentrant les bornes à empêcher également tout dialogue entre les différents répéteurs hertziens.

La solution est généralisable à l’ensemble des clients « nomades » hors problématique réseau sans fil. L’architecture utilisée pour la mise en place de ce type de solution est générique quelque soit les produits VPN achetés par tel ou tel établissement. Pour avoir la totalité des fonctionnalités offertes par le constructeur il faut associer client et boîtier VPN du même constructeur.

3.3.6.1. Le protocole AH A completer !

3.3.6.2. Le protocole ESP A completer !

3.3.7. Solution de type SSL Assez proche d’une solution de type VPN, elle permet une authentification et un cryptage des échanges entre un client et un boîtier central. Accessible via un client http standard sur le poste, il est alors possible à l’utilisateur de bénéficier de toute une panoplie de services à travers cette connexion sécurisée (clients telnet/ssh, applicatifs de déports d'affichage ainsi que l'accès à des services de fichier FTP, etc).



Avantages et Inconvénients pour nous Aucun téléchargement ni installation préalable de client n’est nécessaire. Les fonctions sont disponibles sur le poste dès que l’on dispose d’un client http. A la différence d’un client VPN-ipsec, tous les services ne sont pas disponibles. Le gros problème de cette solution c’est son arrivée très récente sur le marché donc très peu mature.

4. SOLUTION RETENUE PAR LES ETABLISSEMENTS GRENOBLOIS

4.1. L’infrastructure réseau sans fil : un réseau par Etablissement

Chaque établissement a en charge le déploiement dans ses bâtiments de son propre réseau sans fil à la norme 802.11b et 802.11g. Le CICG a en charge le déploiement dans les espaces communs et lieux de vie. Les réseaux sans fil sont déployés en parallèle des réseaux filaires existants. Les commutateurs et fibres utilisés actuellement par les établissements/entités peuvent être utilisés pour desservir les bornes, mais dans un (des) VLAN(s) séparé(s). Un utilisateur du Campus peut se connecter sur n’importe lequel des réseaux sans fil mis en place par tous les établissements. Une fois connecté, il ne peut cependant rien faire tant qu’il ne sera pas identifié/authentifié par son établissement d’origine. Chaque établissement/entité dispose d’une plage d’adresses de la classe A privée 10.0.0.0/8 pour ce déploiement :

• GRENOBLE1 – 10.1.0.0/16 • GRENOBLE2 – 10.2.0.0/16 • GRENOBLE3 – 10.3.0.0/16 • INPG – 10.4.0.0/16 • CICG – 10.5.0.0/16 • IMAG – 10.6.0.0/16

Chaque établissement/entité est ainsi libre de créer en interne un ou plusieurs Vlan avec ses adresses privées. L’affectation des adresses se fait de manière dynamique via un serveur dhcp (mis en place dans chaque établissement). Ainsi tout utilisateur peut librement se connecter sur le campus à un réseau sans fil et se voir attribuer une adresse privée quelque soit le lieu et son établissement d’appartenance. Techniquement rien n’est mis en œuvre au niveau du réseau sans fil pour garantir la sécurité des échanges (pas de Wep, pas de filtrage par adresse mac, …). En conséquence, le/les SSID (Service Set IDentifier) peuvent être choisis et diffusés librement par chaque établissement. Seule contrainte, la normalisation des chaînes de caractères utilisées pour le SSID :

• U1-* • U2-* • U3-*



• INPG-* • CICG-* • IMAG-*

4.2. L’identification / authentification : mise en place d’une

solution à base de VPN Rien n’étant mis en œuvre au niveau sans fil pour garantir la sécurité, le problème est traité au niveau supérieur via une solution de type VPN (Virtual Private Network) avec comme protocole de tunneling IPSec pur. Chaque réseau sans fil est connecté à son établissement d’appartenance via un équipement réalisant du filtrage. Une fois l’utilisateur connecté au réseau privé (il dispose alors d’une adresse privée), il ne peut pas sortir de ce réseau qui est entièrement filtré hormis pour atteindre les équipements de type concentrateur VPN de chaque établissement. Ainsi pour atteindre les ressources du réseau, il utilise un client VPN, se connecte à son établissement d’origine qui l’identifie/authentifie. Une fois cette opération réalisée, un tunnel crypté est établi entre son poste de travail et son établissement d’origine. Chaque établissement peut ainsi librement définir une politique d’affectation des droits utilisateurs qui lui convient. Une base radius peut par exemple aider à réaliser cette opération d’identification/authentification des utilisateurs en fonction de profils tels qu’étudiants, personnels, etc. Pour se faire : Les adresses privées des réseaux sans fil (10.x.y.z) sont routées sur le Campus entre tous les établissements. Chaque réseau sans fil établissement est connecté à un équipement de filtrage qui ne laisse communiquer les adresses privées du réseau sans fil qu’avec les boîtiers VPN identifiés par chaque établissement (le Cicg consolidera ce filtrage au niveau de l’inter-U). Chaque établissement fourni l’adresse publique de son (ses) concentrateur(s) de tunnels VPN pour la mise en place du filtrage. Avantages de la solution Chaque établissement avance à la vitesse qui lui convient sur le déploiement de la solution VPN. Chaque établissement est libre de choisir sa solution VPN ainsi que sa politique d’attribution des droits utilisateurs, (et ce indépendamment de la couverture du réseau sans fil mise en place sur tout le campus). La solution VPN permet d’identifier/authentifier non seulement les utilisateurs du réseau sans fil mais également des éventuels utilisateurs nomades autres. Aucun utilisateur du réseau sans fil ne peut se connecter à une quelconque ressource du campus sans avoir été préalablement identifié/authentifié. Schéma récapitulatif



Wifi 1

Principe d’architecture Wifi campus

Vers le reste du monde

Routeur inter-U

Routeur Etabliss. 1

Serveur Radius

Serveur DHCP

ConcentrateurVPN

Réseaux Etablissement 1

VLAN Wifi Etablissement 1

Routeur Etabliss. i

Serveur DHCP

ConcentrateurVPN

Réseaux Etablissement i

VLAN Wifi Etablissement i

Routeur Etabliss. 2

Filtrage traficWifi/VPN



4.3. Autres sites Le principe retenu sur le campus est reproductible sur les autres campus universitaires. En fonction des besoins et contraintes de déploiement, plusieurs options techniques sont envisageables :

• Chaque établissement déploie une infrastructure locale qui lui est propre (son boîtier VPN, serveur dhcp, etc).

• Les établissements mutualisent les équipements (un boîtier VPN unique pour plusieurs établissements, ainsi qu’un serveur dhcp, …).

• Un routage d’adresses privées est mis en place pour traitement des demandes sur un site distant. En pré requis : bilan (et réaffectation ?) des adresses privées utilisées sur tous les campus, mais aussi validation du routage des adresses privées sur le réseau métropolitain avec les autres acteurs (CNRS, etc.) et enfin choix du traitement des requêtes dhcp (local, utilisation du dhcp-relay…).

4.4. Déploiement des serveurs

Chaque établissement est évidemment libre de choisir ce qu’il désire pour répondre à la demande des services identifiés ci-dessous.

4.4.1. Serveurs radius

4.4.1.1. Exemple du CICG Le Cicg utilise actuellement un serveur Radius (freeradius) pour les accès distants. La base utilisateurs comporte actuellement environ 400 comptes.



Dans un premier temps, ce serveur sera celui utilisé pour identifier les utilisateurs du CICG.

4.4.2. Serveurs DHCP

4.4.2.1. Exemple du CICG Actuellement est mis en œuvre un « petit » service dhcp directement sur le routeur du Cicg. Ceci n’est valable que temporairement mais dès la montée en charge de la demande inter-U (lieux de vie, cafeterias, …), un serveur dédié plus conséquent sera déployé (pas encore choisi mais il tiendra compte de l’existant dans les établissements). Pour ce qui est de sa localisation, il sera installé dans la classe d’adresse privée dédiée au Wifi (cela permet de restreindre au maximum tout paquet ayant le droit de sortir du réseau logique wifi).

4.4.3. Serveurs HTTP et FTP

4.4.3.1. Exemple du CICG Pas encore d’avis technique sur ce point.

4.5. Gestion du réseau Wifi

4.5.1. War driving Préconisations matériel Solution 1 : Logiciel NetStumbler

4.5.2. Maintenance du réseau Gestion d’une cartographie de l’implémentation de bornes et des fréquences.

4.5.3. Sécurité et VPN A noter un point important : dans le contexte d’utilisation d’une solution à base de VPN comme explicité ci-dessus, il est nécessaire que chaque établissement permette à tout client extérieur de venir se connecter sur le/les boîtiers VPN. Ce point semble être un détail, mais il impose de revoir les filtres sur chaque équipement d’entrée de tous les établissements (routeur en général) pour permettre à un nomade quelconque de se connecter sur le boîtier VPN de son établissement d’origine :

- Ouverture du filtrage pour les protocoles AH (51) et ESP (50), - Ouverture du filtrage pour les paquets UDP sur le port 500.

5. LES MATERIELS TESTES

5.1. Les points d’accès



Globalement toutes les bornes 802.11b semblent passer les tests de base en utilisation de type hotspot (cf message de jerome le tanou dans la liste ip). Aucun cas rapporté de borne ne fonctionnant pas avec telle ou telle carte cliente. Deux bornes ont été utilisées pour un congrès sur Grenoble cet été (une de type netgear et une de type Linksys). Aucun test de performance n’a été réalisé mais les bornes ont fonctionné pendant plusieurs jours à la grande satisfaction des utilisateurs… (Petit test unitaire sur le coin d’une table réalisé entre une borne linksys 802.11G draft et une carte linksys 802.11G seule abonnée à la borne :

• Ftp à 10 Mb/s sans utilisation de VPN pour un niveau de signal égal à 100%, • Ftp à 7 Mb/s avec utilisation de VPN (cryptage AES 128 bits) pour un niveau de

signal de 100%, • Ftp à 1,5 Mb/s sans utilisation de VPN pour un niveau de signal égal à 20 %)

On semble se diriger vers deux types effectifs de bornes :

- les bornes à bas prix pour les utilisations de type hot-spot, - les bornes plus onéreuses capables de fonctionnalités plus avancées.

Dans le cadre d’un déploiement de celui qui est envisagé actuellement sur le campus, le second type est bien entendu conseillé avec comme fonctionnalité essentielle l’interdiction des communications entres les clients d'une même borne (fonction "Public Secure Packet Forwarding" chez Cisco, Fonction "Local Bridge Filter" chez Nortel Networks, "Station to station bridging" chez Extreme Networks). Chez Nortel Network il y a également une fonction "AP management Filter" sur les bornes qui interdit tout accès au management de la borne depuis un client Wireless. En ce qui concerne le tests de ces fonctions évoluées et très récentes (filtrage des communications, alimentation POE, vlan, etc), pas de remontées effectives de tests jusqu’à ce jour.

5.2. Les dispositifs d’identification / authentification / cryptage

5.2.1. Les solutions VPN

5.2.1.1. Solution Cisco 3000 La prise en main est très facile au travers de l’interface Web. Le manuel d’aide intégré au serveur web d’administration du matériel est assez complet. Il permet d’avoir un complément d’information sur les paramètres. Les protocoles et fonctionnalités proposées sont riches, les clients VPN cisco gratuits. A noter des problèmes d’intégration d’un boîtier de type 3005 au sein de l’architecture ospf du campus (pb d’intégration de routes host et réinjection via ospf). Un ticket d’incident a été émis pour solutionner le problème.

5.2.1.2. Solution Nortel Contivity



Solution techniquement intéressante mais ayant un inconvénient gênant pour nous : les clients sont payants…

5.2.1.3. Solution HP VPN Hewlett-Packard ProCurve 760wl Le HP ProCurve 760wl fait partie de la nouvelle gamme de produit HP ProCurve Secure Access 700wl composée - pour l'instant - des modèles 720 (contrôleur d'accès en périphérie) , 740 (gestionnaire d'administration central) et 760 (à la fois contrôleur d'accès et gestionnaire d'administration). C'est une gamme de produits qui est commercialement très orienté sur le contrôle et la sécurisation des réseaux sans fils mais qui - à notre avis - peut très bien être utilisé pour des réseaux filaires. Sa sortie commerciale en France est prévue officieusement - source provenant de la société ARES/RCS - début Novembre 2003 (?), alors que le produit a été commercialisé aux US depuis le printemps et à partir de Juin en Europe (du moins en Allemagne, en Italie et au Royaume Uni). Ce produit fait partie d'une gamme aux profils techniques riches et intéressants. Bien qu'il puisse apparaître comme étant relativement complexe de mise en oeuvre - support de nombreux protocoles - l'interface d'administration bien pensée simplifie beaucoup les choses. La possibilité d'avoir plusieurs types de carte d'extension ainsi "qu'un appliance" évolutif est également à signaler. Par contre, le manque de maturité de certains outils d'administration, les incompatibilités de connexion des clients VPN et d'authentification LDAP sont embarrassantes.

5.3. Les solutions SSL Solution F5 FirePass 1030 Ce produit qui est relativement récent dans la gamme des produits F5 Networks est issue du rachat en Juillet 2003 de la société uRoam Inc. Il se présente sous la forme d'un chassis rackable de 19" équipé de 2 interfaces réseaux RJ-45 10/100 base-T. Il permet un accès sécurisé à travers un navigateur Web, supportant le SSLv3 et la gestion des cookies aux applications "Webisés" sans aucune installation de logiciel sur le poste client. Il permet aussi à travers l'interface de connections Web de l'utilisateur, la possibilité d'accéder à des clients telnet/ssh ou des applicatifs de déports d'affichage ICA, RDP, VNC et X-Windows ainsi que l'accès à des services de fichier FTP, CIFS ou NFS. Ce produit nous a semblé manquer encore de maturité. Beaucoup des nombreuses fonctionnalités présentes sont exploitables mais elles manquent encore de finitions ou d'améliorations. De plus à travers certaines de ses fonctionnalités, c'est pour l'instant une solution très orientées pour le monde Windows (utilisation des plugins ActiveX), des développements futurs sont prévu pour les mondes Linux (Unix ?) et MacOS en Java. Un problème - plus francophone - existe aussi autour de la localisation du firmware (principalement sur les interfaces de connexion et d'aide utilisateurs).



Le prix public est encore relativement important comparé aux solutions plus traditionnelles de VPN. Avis sur les solutions VPN-SSL A noter dans le domaine des concentrateurs VPN-SSL, la mouvance de l'offre actuelle. De nombreuses "startups" ont été rachetées (uRoam par F5, Neoteris par NetScreen et WebSafe par Symantec) ou vont l'être par des équipementiers ou des éditeurs plus importants. A mon avis, le VPN-SSL est LA SOLUTION d'avenir pour l'établissement de connections sécurisées mais ceux sont des produits qui manquent encore de maturité. Il est là aussi - un peu comme pour ipv6 mais pas pour les mêmes raisons - urgent d'attendre.

5.4. Les solutions de type Firewall Les firewall permettent généralement des filtrages plus évolués que les concentrateurs VPN dédiés. Cependant, à part quelques solutions basées sur des accélérateurs hard, les firewall étant souvent basés sur des Os (sun, nokia, …) les performances sont moindres que sur des boîtiers VPN dédiés. Là encore, les clients sont divers : à noter des solutions pour palms

5.5. Les commutateurs à la norme 802.3af Foundry et 3Com n'attendront pas la ratification du standard 802.3af pour commercialiser leurs produits PoE (Power over Ethernet). Ils ont profité du Cebit 2003 pour annoncer la disponibilité de produits « compatibles 802.3af ». 3Com, le plus ambitieux des deux équipementiers, a dévoilé sa gamme de produits alimentés via Ethernet composée d'un commutateur 24 ports 10/100 4400PWR, de trois points d'accès sans fil (8200, 8500, 8700) et des téléphones IP NBX2101 PE. De son côté, Foundry a présenté deux switchs de niveau 2/3, les Fast Iron Edge 2402 et 4802, dotés respectivement de 24 et 48 ports 10/100 Mbit/s Ethernet. Les constructeurs insistent sur l'intérêt d'une administration centralisée de l'alimentation électrique. Ainsi, les commutateurs 4400 PWR de 3Com sont dotés de fonctionnalités de supervision et de contrôle de l'alimentation, avec émission d'alarmes en cas de d'incidents. Ils peuvent même garantir une alimentation électrique sans coupure à certains téléphones «prioritaires», tels ceux d'une salle de classe. Quant aux commutateurs de Foundry, ils sont équipés d'un mécanisme de détection automatique des appareils utilisant l'alimentation électrique via le LAN, et adaptent la puissance électrique distribuée en fonction des terminaux. Aujourd'hui, excepté 3Com et Foundry, d'autres équipementiers disposent de commutateurs « compatibles » 802.3af comme Nortel et son commutateur 24 ports 10/100 Baystack 460 PWR, lancé fin 2002, ou Avaya, avec son switch 24 ports 10/100 P333T PWR. Quant à Cisco, comme nous l’avons expliqué au chapitre précédent, il a choisi de faire cavalier seul en développant sa propre technologie Inline Power (disponible sur certains commutateurs Catalyst 3500, 4000 et 6500). (Le paragraphe ci-dessus provient d’un l’article du magazine « Réseaux & Télécoms » mis en ligne le 11/04/2003 par Alain COFFRE)



Annexes URLs Dossier « Les réseaux locaux radioélectriques ou RLAN / Wi-Fi » de l’ART http://www.art-telecom.fr/dossiers/rlan/menu-gal.htm Recommandations pour le déploiement de réseaux sans fil sur le campus de Jussieu http://web.ccr.jussieu.fr/ccr/csr/reseaux_sans_fil/sansfil.htm SMAC : MAC Address Modifying Utility for Windows 2000 and XP systems http://www.klcconsulting.net/smac/ Anomalies de performances des réseaux Wi-Fi http://drakkar.imag.fr/news/perf.html Problème de performance dans les réseaux Wi-Fi (basé sur l'analyse précédente) http://www.vnunet.fr/actu/article.htm?numero=11218 Sécurité des réseaux sans fil 802.11b http://www.actuasite.com/spip/IMG/pdf/Securite_des_reseaux_802.11b.pdf http://ouah.kernsh.org/wlan-security.html EEE Wireless Standards Zone. http://standards.ieee.org/wireless/ http://standards.ieee.org/getieee802/download/802.11-1999.pdf Quelques recettes simples permettent de limiter les failles d'un réseau Wi-Fi http://www.01net.com/article/209432.html Les réseaux sans-fil en six points. http://solutions.journaldunet.com/0111/011115_faq_sansfil.shtml WARDRIVING http://reseaucitoyen.be/index.php?WarDriving http://www.securite.teamlog.com/publication/6/10/220/ La sécurité des réseaux est-elle compromise avec l’arrivée du sans-fil et des réseaux virtuels privés (VPN) http://www.viagenie.qc.ca/en/doc/cours/crim2002.pdf CERTA : Sécurité des réseaux sans fil utilisant la norme 802.11b (Wi-Fi) http://www.certa.ssi.gouv.fr/site/CERTA-2002-REC-002/



Livre blanc sur l’utilisation du Wifi http://www.cyber-networks.fr Dossier Terena sur le sujet de la mobilité http://www.terena.nl dossier Mobility Liste des compatibilités entre équipements VPN http://www.vpnc.org Secrétariat Général de la défense nationale http://www.ssi.gouv.fr/fr/actualites/Rec_WIFI.pdf



Détails des tests effectués Solution HP VPN Hewlett-Packard ProCurve 760wl Le HP ProCurve 760wl fait partie de la nouvelle gamme de produit HP ProCurve Secure Access 700wl composée - pour l'instant - des modèles 720 (contrôleur d'accès en périphérie) , 740 (gestionnaire d'administration central) et 760 (à la fois contrôleur d'accès et gestionnaire d'administration). C'est une gamme de produits qui est commercialement très orienté sur le contrôle et la sécurisation des réseaux sans fils mais qui - à notre avis - peut très bien être utilisé pour des réseaux filaires. Sa sortie commerciale en France est prévue officieusement - source provenant de la société ARES/RCS - début Novembre 2003 (?), alors que le produit a été commercialisé aux US depuis le printemps et à partir de Juin en Europe (du moins en Allemagne, en Italie et au Royaume Uni). Il se présente sous la forme d'un serveur "appliance" rackable (2 U). Le châssis ne dispose que d'une seule alimentation électrique de 460W (pas de redondance électrique possible), il apparaît relativement bien ventilée et suffisamment silencieux pour une salle machine ou un local technique. La face avant est composé d'un écran LCD, des habituels boutons et diodes de contrôle, d'un port "console" de connexion locale et de 2 interfaces réseaux. Ces interfaces sont composés d'un port RJ-45 10/100/1000Base-T pour « uplink » et d'un port RJ-45 10/100Base-T marqué "reserved" (évolutivité future ou surplus ?). Il dispose de 3 slots pour les cartes d'extensions accueillant les ports descendants (carte 4 ports RJ-45 10/100Base-T - d'origine Vernier Networks, 1 port RJ-45 10/100/1000BaseT, 1 port LC Giga-LX ou Giga-SX). Une carte d'accélération de cryptage (DES, 3DES, HMAC MD5 et SHA-1) peut également être installé ainsi qu'une future carte Fiber Channel. Le modèle testé était équipé d'une carte "de downlink" de 4 ports RJ-45 10/100Base-T - contrôleur Ethernet d'origine Tyan - qui contrairement au port "d'uplink" ne dispose pas d'interface Auto-MDI (utilisation de câble croisé). Je dispose de peu d'information sur "le hardware" du modèle (CPU, RAM, etc..) si ce n'est que seul les modèles 740/760 dispose d'un disque dur, le modèle 720 étant équipé d'une mémoire flash de 256 Ko. L'OS est un FreeBSD (4.3/4.4 ou 5.0 d'après la prise d'empreinte "Nmap") et les principaux services logiciels sont assurés par Apache, OpenSSL, GNU Portable Threads, IBM/Whistle Communications. La version du firmware utilisé après une mise à jours a été la 3.1.111 (3.1.105 à la livraison). Performance de routage/communication annoncé par HP: ~300 Mbps. En terme de sécurité, j'ai utilisé les protocoles suivants parmi de nombreux autres possible et disponible:

• tunnel IPSec en mode ESP avec authentification IKE (Internet Key Exchange) par partage de clés secrètes (support complet de gestion PKI également disponible mais non testé) et tunnel SSH v1 et v2.

• cryptage AES, DES et 3DES, Blowfish, CAST. • authentification, échange de clé et contrôle d'intégrité MD5, SHA-1, HMAC MD5 et



SHA-1, Diffie-Hellman (groupes 1,2 et 5). • plusieurs types de filtrage sont possible notamment au niveau Ethernet avec la

possibilité d'importation d'une base d'adresse MAC depuis un annuaire LDAP, ainsi qu'au niveau VLAN, IP (TCP/UDP,ICMP), adressage et nommage IP.

• contrôle d'accès géographique (par groupe d'utilisateurs, par point d'accès wifi, par vlan, par interface "de downlink", etc..) et temporel (en fonction de date, de l'heure, de minuterie d'inactivité ou de duré de session).

• usurpation d'adresses Ethernet (anti-MAC spoofing) et contrôle du trafic de diffusion.

Les clients VPN supporté sont pour:

• MacOS 9: PGP PGPnet et LAN Builder (uniquement en PPTP), MacOS X (?) • Unix: aucun .. none, nada, kedale .. ;-) • Win9x et Winxx: Microsoft ( L2TP et PPTP), NetScreen, PGP PGPnet, SafeNet

SoftRemote, SSH Sentinel. Pour les clients VPN IPSec "purs", 1 seul d'entre eux possède une version d'évaluation ce qui n'a en rien facilité le déroulement des tests. En résumé, aucun client VPN IPSec multi plateformes (MacOS, Unix et Windows) et encore moins gratuit. Pour information, je ne suis pas arrivé à faire fonctionner le client Cisco VPN (version Windows 4.02D) avec ce concentrateur. En terme de réseau, cet équipement supporte notamment les protocoles :

• DHCP: serveur configurable (en mode NAT) et relais (en mode IP natif). • NAT/PAT avec plage personnalisable ou never-NAT. • support de connexion cliente via un proxy HTTP/HTTPS. • roaming des clients entre les sous-réseaux (continuité de session). • à noter le support des VLAN (802.1Q) avec fonctions de tagging, re-marquage et

trunking automatique (non testé) sur tous les ports. L'authentification des utilisateurs peut être assurée soit

• par la création d'une base de données intégrée (import XML possible), • soit via une interface à un annuaire LDAP v2/v3 (mode user ou non-user binding), • une base Radius (non testé), • Kerberos (non testé), • XML-RPC (non testé), • un domaine NT ou Active Directory (non testé), • MS-CHAP v1/v2 (non testé) ou • 802.1X (non testé).

Les pages HTML (interception du 1er trafic HTTP en provenance d'un client) de (dé)connexion sont personnalisables et contextuelles. L'authentification de groupes d'utilisateurs peut être assuré soit par une base de donnés intégrés (import XML possible) ou soit via une interface à un annuaire LDAP v2/v3 (non testé). L'administration est assuré via une interface Web sécurisé (HTTPS) ou via CLI mais



uniquement accessible à partir du port console (et nécessaire pour la configuration initiale). L'interface Web est relativement simple de prise en main, légère et bien faite. Le système de logs de type Unix est complet. De plus, il y a le support de client Syslog, de client NTP (v3) et des fuseaux horaires standards ainsi que d'un agent SNMP (compatible MIB2) mais en lecture seule. En terme d'utilitaires de dépannage, on trouve:

• au niveau 2 (Ethernet): des outils CLI de debug de trafic, le support du Cisco CDP, du Symbol Technologies WNMP (Wireless Network access Management Protocol), AppleTalk (bridging) et la possibilité de rajouter le support d'autres protocoles en utilisant l'utilitaire "tcpdump" (par ex pour IPX/SPX).

• au niveau 3 (IP): des outils CLI de debug TCP et les habituels "ping", "traceroute" et "nslookup" mais pas encore "dig" (!).

• au niveau applicatif, il est à noter la présence d'un utilitaire "Troubleshooting" (uniquement accessible via l'interface Web) de debuggage d'authentification utilisateur locale/LDAP/Radius/Kerberos/XML-RPC pratique et plutôt bien fait.

La mise à jour du firmware est assuré via du TFTP, FTP ou HTTP avec la possibilité d'utiliser une clé numérique et de conserver 2 versions différentes en local. La sauvegarde/restauration de la configuration et/ou de la base de donnés intégrés est faite sous forme d'une image binaire (non exploitable) en local ou exportable/importable via du FTP. Pour de plus amples informations sur cette gamme de produit:

• http://www.hp.com/rnd/library/index.htm • http://www.hp.com/rnd/support/index.htm

Cet équipement nous a été prêté par la société ARES/RCS pendant une période de 8 jours .. ouvrables .. ;-) .. avec la possibilité d'avoir un support technique auprès de HP France. Cette courte période de prêt est principalement du à la toute récente disponibilité de ce produit. Les tests à partie des postes clients ont été réalisé avec 3 PC sous Windows et Linux, dans un VLAN "client" indifféremment connectés au réseau Ethernet en filaire ou en hertzien. Principaux problèmes ou incidents rencontrés

• Authentification utilisateur impossible entre le 760 et un serveur OpenLDAP uniquement compatible avec la version 3 du protocole. Dans sa documentation, HP ne mentionne en effet que le support LDAP v3 pour MS-Active Directory ou Sun iPlanet, mais du LDAP v3 c'est normalement compatible avec du LDAP v3 (sauf pour MS-AD .. cela je le sais déjà). Le problème est remonté au support technique de HP Europe (HP France ne pouvant pas assurer le support sur ce problème là) -> pas de solution proposé pour l'instant.

A mon avis, le client LDAP du 760 n'émet ses requêtes qu'en LDAP v2 (problème identiquement rencontré sur un concentrateur VPN-SSL d'un autre constructeur).

• Le CDP n'a pas l'air de fonctionner correctement. Les interfaces du 760 étaient connectés sur des switchs Cisco Catalyst ayant le support du CDP activé, il a été impossible de le voir dans "le voisinage CDP" de ces switchs là ainsi qu'a partir du



logiciel Cisco CWSI (NMS utilisant la découverte SNMP/CDP) -> ce problème n'a pas été remonté au support technique HP.

• Il faudrait avoir une liste des clients VPN réellement supportés, il semble que ce concentrateur VPN souffre lui aussi d'incompatibilités avec certains logiciels clients VPN -> pas de réponse proposé pour l'instant.

• Il faudrait récupérer les performances et le nombre de clients simultanés supportés en IPSec "pur" avec et sans carte d'accélération -> pas de réponse pour l'instant.

• Son Prix (et oui cela fait aussi partie des problèmes): réponse d'ARES/RCS du 8/9/03:

Comme suite à notre conversation téléphonique, vous trouverez ci-dessous vos prix remisé concernant l'acquisition d'Access Controler HP.

• Le 720: 3.308 Euros H.T • Le 740: 5.004 Euros H.T • Le 760: 6.658 Euros H.T

Conclusions Ce produit fait partie d'une gamme aux profils techniques riches et intéressants. Bien qu'il puisse apparaître comme étant relativement complexe de mise en oeuvre - support de nombreux protocoles - l'interface d'administration bien pensée simplifie beaucoup les choses. La possibilité d'avoir plusieurs types de carte d'extension ainsi "qu'un appliance" évolutif est également à signaler. D'autres part, le rapport fonctionnalité/prix est intéressant comparé aux solutions VPN Cisco ou Nortel par exemple (x2/x3). Par contre, le manque de maturité de certains outils d'administration, les incompatibilités de connexion des clients VPN et d'authentification LDAP et le manque de réactivité actuel du support technique HP France (ou Europe) sont vraiment embarrassantes. NB: Cette gamme de produit ressemble comme «2 gouttes d'eau »aux offres AM/CS 6500 de Vernier Networks (http://www.verniernetworks.com/).



Solution Cisco 3000 La prise en main est très facile au travers de l’interface Web. Le manuel d’aide intégré au serveur web d’administration du matériel est assez complet. Il permet d’avoir un complément d’information sur les paramètres. Suivi des connexions : Le suivi des connexions peut se faire en temps réel : très utile pour déterminer le problème d’une connexion. Les historiques des connexions peuvent être renvoyées sur un serveur de log. Protocoles implémentés : Tunneling mode : IPSec, PPTP, L2TP, L2TP over IPSec Encryptions : DES, 3DES, AES Vis-à-vis de l’encryption le protocole AES est le plus interessant : c’est le plus récent, il est plus robuste et le temps de cryptage est plus performant que le Triple DES. Cependant l’encryption AES fonctionne uniquement avec les clients cisco pour l’instant et uniquement en 128 bits (le protocole AES existe en 128, 192 et 256 bits). Dans le cas du déploiement wifi, si on utilise uniquement des clients VPN cisco on peut opter pour le protocole AES, si d’autres clients doivent être utilisés il faudra opter pour le protocole Triple DES. Authentification : CA, Radius, TACACS+ Fonctionnalités : Le split tunneling : Le split tunneling fonctionne uniquement avec les clients VPN cisco. Le nombre de tunnels donc de ressources aux niveaux VPN diminue si l’on utilise ce procédé. Le split tunneling est un mode qui ne sera pas utilisé par les nomades wifi. Au niveau OSPF : Si l’on utilise la fonctionnalité normalisée des mots de passe MD 5 pour le protocole de routage OSPF, il faut savoir que pour l’instant les VPN 3000 savent gérer des mots de passe de 8 caractères au maximum. De même, la valeur de la clé passée en paramètre ne peut-être modifié, elle est fixée à 1 : (ip ospf message-digest-key 1 md5 7 0700325C46441D17) Les clients VPN cisco : Ils sont gratuits et disponibles sur de nombreuses plates-formes : Win9x, NT, 2000, XP, Mac OS X, Linux kernel 2.2 et 2.4, Sparc Solaris Le client VPN cisco sous windows intègre un firewall de type Statefull Inspection (firewall dynamique). Il est très efficace vis-à-vis d’intrusions extérieures. Il peut-être activé même sans une connexion VPN. C’est une solution de sécurité à envisager pour protéger les postes clients sans dégrader les performances du routeurs. D’autant plus que suivant les



droits du client il peut l’activer ou le désactiver. Problèmes rencontrés : Sous windows NT le mode démarrage du client à l’ouverture de la session avec le client VPN 4.0.3 ne fonctionne pas. Le problème a été résolu en installant le client VPN 3.6.6. Pour passer du client VPN 4.0.3 au client 3.6.6, il faut supprimer le fichier /winnt/system32/CSgina.dll. Windows 95 est compatible uniquement avec la version 3.6 du client VPN cisco. Difficultés à utiliser ospf pour un boîtier VPN 3005 dans une area fille (pb d’export des routes en /32 pour une utilisation radius avec affectation d’adresse par utilisateur). A noter une version ssl existante en beta, (pas encore testée) mais qui dans les documents constructeur divise par 4 les performances par rapport à une utilisation de type VPN.



Solution F5 FirePass 1030 Le FirePass-1030 fait partie de la nouvelle gamme de concentrateur VPN-SSL de la société F5 Networks issue du rachat de la société uRoam en Juillet 2003. Il se présente sous la forme d'un serveur "appliance" rackable 19" de 1U de hauteur. Le châssis ne dispose que d'une seule alimentation électrique de 200W (pas de redondance électrique possible), il est correctement ventilé et suffisamment silencieux pour être installé dans une salle machine. La face avant est composé d'un écran LCD, des boutons et leds de contrôle habituels, d'un port "console" et de 3 interfaces réseaux RJ-45 10/100Base-T. Seule 2 interfaces sont réellements utilisables, la troisième étant "un surplus" du constructeur du châssis qui - d'après les adresses Ethernets - semble être Advantech. Cette série de FirePass 1000 est prévu pour pouvoir supporter une centaine de connections clientes simultanées, un millier pour la série FirePass 4000 avec en outre la possibilité de mettre en place une solution "de clustering" et d'équilibrage de charge pouvant supporter jusqu'à 10000 connections. Il existe également la possibilité de mettre en oeuvre une solution de "hot-statefull failover" entre 2 boîtiers - l'un étant actif et l'autre "en sommeil". Le firmware tourne sur un OS Linux (2.4.0 - 2.5.20 d'après la prise d'empreinte "Nmap"). Les principaux services sont assurés par des logiciels "libres" (Apache, OpenSSL ou OpenLDAP par ex). L'unique version du firmware utilisée durant les tests a été la 4.0. La 4.0.1, contenant notamment la correction de certains bugs que nous avions remontés au support technique, arrivant trop tard dans le cadre de nos tests. Le déploiement du FirePass c'est effectué en quelques heures avec la présence d'un ingénieur avant-vente de F5 Networks France et la configuration a put être par la suite facilement modifié suivant nos besoins (utilisation d'une seule ou des deux interfaces ethernets, architecture réseau différente). La configuration initiale peut être effectuée soit en mode Terminal via le port console ou en mode Web via un navigateur (en utilisant la pré-configuration réseau fournit par F5). Les paramètres de configuration système et réseaux (IP, NetBIOS, SNMP, proxy, etc...) sont standards. A noter l'importance d'avoir un nom DNS FQDN et résolvable (utilisation des certificats X.509) et l'ajout obligatoire des licences d'utilisations des services que nous souhaitions testés (et de plus limité dans le temps). L'administration et la surveillance sont assurés à travers l'interface Web (sécurisation des accès à l'aide de filtrage IP sur des adresses de machines ou de réseaux ) via de nombreux logs (exportables au format Microsoft XLS !), des graphes périodiques sur l'état et l'activité des différents composants du système, des statistiques sur les performances et les connections, de la capture du trafic IP avec un export possible au format "libpcap" (ethereal, tcpdump, etc...) et l'envoi de courriels vers un compte d'administration. La sauvegarde/restauration - partielle ou complète - de la configuration, de la base de donnés intégrés et des logs mais pas de la configuration réseau (!) est faite sous forme d'une image binaire (zippé) sur la machine d'administration.



La mise à jour du firmware ainsi que la notification automatique de nouvelles versions se font à partir de l'interface Web. Il n'est pas possible de disposer de plusieurs versions de firmware sur le même FirePass et il est fortement déconseillé "de downgrader" une version. Le FirePass est initialement déployé avec un certificat pré-installé (utilisation en auto-certification) qui peut être - qui doit l'être en exploitation - remplacé par un certificat valide. Les listes de révocations (CRL) sont également supportées. Parmi certaines fonctionnalités, a noter les possibilités: - de monter des tunnels VPN IPSec entre le FirePass et d'autres serveurs ou réseaux - de rajouter l'utilisation de routes statiques (avec prioritisation) - d'accorder une partie ou la totalité des privilèges d'administration à d'autres utilisateurs autre que l'administrateur - de définir le comportement (images, colorisations, etc...) des navigateurs clients en fonction de l'entête HTTP d'identification UserAgent - de paramétrer le comportement du cache des navigateurs clients - de forcer le vidage du cache des navigateurs clients à la déconnexion (mais en ActiveX !) - de compresser (en gzip) le trafic entre le FirePass et ses navigateurs clients. A noter également, la présence "d'une backdoor" SSH nécessaire au support technique pour (re)prendre la main sur le FirePass. L'authentification des utilisateurs peut être assuré soit par une base de donnée locale au FirePass (création manuelle) ou bien depuis l'importation d'un fichier texte au format CSV, d'un annuaire LDAP ou bien du PDC d'un Domaine Windows (NT ou AD). Il existe également la possibilité de rediriger les authentifications auprès de serveurs HTTP, LDAP, RADIUS et Domaine Windows (NTLM ou NetLogon). Dans ce cas là, le compte de utilisateur est créé automatiquement sur le FirePass lors de sa 1er connexion. A noter la possibilité d'authentification double par "des tokens" RSA SecurID ou via un serveur VASCO Digipass. Chaque utilisateur doit être associé au minimum à un groupe pour pouvoir être authentifié. Ces groupes sont soit créés manuellement, ceci permettant d'avoir différents profils "aux besoins" ou bien importé depuis "un mapping" à partir d'un annuaire LDAP, d'une base RADIUS ou d'un Domaine Windows. Il est possible de customiser une partie (texte, couleur, icône et logo) de l'interface standard de connexion de l'utilisateur, qui pour le moment n'est disponible qu'en Anglais, une version "francophone" étant prévue pour la version 4.1 (2004Q1). Pour une customisation plus approfondie, notamment pour résoudre les problèmes de localisation, on peut rediriger, après authentification et suivant son groupe d'appartenance, l'utilisateur vers un autre site Web qui lui sert à ce moment là d'interface de connexion. Une fois authentifié, le FirePass permet à l'utilisateur une connexion sécurisé à travers un navigateur ayant un support - correct ! - du SSL v2/v3 (au mieux support du 3DES, pas encore celui de l'AES) et de la gestion des cookies.



Les tests côté postes clients ont été réalisé à partir de différents LAN (IMAG, UPMF), OS (Linux, MacOS X, Windows) et navigateurs (Konqueror, Internet Explorer, Mozilla). Pour de plus amples informations sur cette gamme de produit: http://www.f5.com/f5products/FirePass/ http://tech.f5.com/home/firepass/ Principaux problèmes ou incidents rencontrés durant les tests: - lors d'une authentification utilisateur externe au Firepass (LDAP, RADIUS, etc..), il est créé en local un compte qui ne peut être modifié ou détruit que manuellement par l'administrateur (pas de destruction automatique à la déconnexion de l'utilisateur) - erreur d'exécution de certains scripts PHP dans l'interface d'administration empêchant la configuration ou l'utilisation de certaines fonctionnalités "Network Packet Dump", "Telnet Access", etc... -> corrigé dans la version 4.0.1 - perte de la métrologie existante lors d'un redémarrage des services suite à la modification du paramétrage des fuseaux horaires - nombreuses remontées d'alarme sur des lectures erronées de basses tensions d'alimentation de la carte mère -> corrigé dans la version 4.0.1 - de nombreux problèmes pour l'établissement de connexions FTP (en mode actif, pas en mode passif) principalement à partir des clients FTP intégrées aux différents navigateurs Web (souvent non paramétrable) - authentifications LDAP en v2 mais pas en v3 -> corrigé dans la version 4.0.1 - l'envoi de courriels SMTP vers un compte d'administration n'a jamais put fonctionner malgré de nombreux tests ! - mise en place de certificat X.509 valide. Tous les tests ont du se dérouler avec le certificat pré-installé par F5 Networks (auto-certification et FQDN invalide), Il nous a été impossible de mettre en place un certificat personnel (via l'Infrastructure de Gestion de Clés du CNRS). - multiple login simultané administrateur (ou équivalent) possible -> le dernier des login "admin" qui sur les mêmes paramètres valide quelques choses à raison ! - l'utilisation de certaines fonctionnalités (par ex AppTunnels ou SSL VPN) à partir d'un navigateur client provoque l'apparition de mini-fenêtre Web "Pop-up" de session en plus de la fenêtre Web support de la fonction. Tant que ces mini-fenêtres ne sont pas fermées, elles assurent la continuité de cette session ... indifiniment ! -> corrigé dans la version 4.0.1. Conclusion Ce produit qui est relativement récent dans la gamme des produits de F5 Networks, n'est pas encore complètement "F5-isé" (connaissance et maîtrise par le support technique, incorporation des technologies "maisons"). Il nous a semblé encore manquer de maturité. De nombreuses fonctionnalités présentes sont exploitables mais elles manquent de finitions ou d'améliorations. Le support des applicatifs IP est loin d'être complets, par ex pour les clients de messagerie mais sont promis à des ameliorations (payantes pour certaines). De plus, à travers certaines de ses fonctionnalités avancées, c'est pour l'instant une solution très orientés pour le monde Windows (utilisation de plugins ActiveX, de tunnels MS-PPTP), des développements futurs sont prévus pour les mondes Linux (Unix ?) et MacOS-X à base de Java. Il est à noter que ce produit n'est pas uniquement orienté



à travers son utilisation pour des navigateurs Web de PC mais aussi vers ceux des Mobiles (PDA, WAP, iMode). Le prix public est encore relativement important comparé aux solutions plus traditionnelle de VPN, il faut compter un prix d'achat multiplié par 4 ou 5.

Préconisations nomadisme et déploiement de réseaux locaux ... · 3.1. Les bornes sans fil...

Documents

Transcript of Préconisations nomadisme et déploiement de réseaux locaux ... · 3.1. Les bornes sans fil...