Préconisation Grenet - Comité Réseau des Universités

Transcription

Préconisations
nomadisme
et
déploiement
de réseaux locaux sans fil
Universités de l’académie de Grenoble
Version 4.02
1/12/2003
Draft
Page 1 sur 29
Nomadisme et Wifi
Universités de Grenoble
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.
3.2.2.
3.3.
L’identification/authentification/cryptage __________________________________ 7
3.3.1.
3.3.2.
3.3.3.
3.3.4.
3.3.5.
3.3.6.
3.3.7.
4.
Le SSID : Service Set Identifier _________________________________________________ 7
Protocole WEP : (Wired Equivalent Privacy) _______________________________________ 8
Filtrage par adresse MAC _____________________________________________________ 8
Solution de type 802.1x/EAP ___________________________________________________ 9
Solution de type 802.11i ______________________________________________________ 9
Solution de type VPN IPSec __________________________________________________ 10
Solution de type SSL ________________________________________________________ 10
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.
4.4.2.
4.4.3.
4.5.
Serveurs radius ____________________________________________________________ 13
Serveurs DHCP ____________________________________________________________ 14
Serveurs HTTP et FTP ______________________________________________________ 14
Gestion du réseau Wifi ________________________________________________ 14
4.5.1.
4.5.2.
4.5.3.
5.
Brouillage__________________________________________________________________ 7
ARP Poisoning______________________________________________________________ 7
War driving________________________________________________________________ 14
Maintenance du réseau ______________________________________________________ 14
Sécurité et VPN ____________________________________________________________ 14
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
Preconisations-wifi-v4.doc
2
Nomadisme et Wifi
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.
3
Nomadisme et Wifi
Tableau récapitulatif des normes de transmission
802.11 b
2,4Ghz
de 2,4-2,4835Ghz
802.11 g
2,4Ghz
2,4-2,4835Ghz
802.11 a
5Ghz
5,150-5,725Ghz
802.11 b
aucune
Fréquence
Bande
fréquences
les débits
11 Mbits/s théorique 54 Mbits/s théorique 54 Mbits/s théorique
Nombre de bandes 13
13
19
de
fréquences
(canaux)
Le
nombre
de 3
3
8
bandes
de
fréquences
sans
recouvrement
Compatibilité
aucune
Les lois de la radio
Débit plus grand
Puissance d’émission élevée
Fréquences radio élevées
= Couverture plus faible
= Couverture plus grande, mais durée de
vie des batteries plus faible
= 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).
4
Nomadisme et Wifi
Fréquences en MHz
2400
Intérieur
100 mW
Extérieur
100 mW
2454
2483,5
Fréquences en MHz
5150
5250
5350
10 mW
Intérieur
Extérieur
200 mW
impossible
200 mW avec DFS/TPC
ou
équivalent
impossible
ou 100mW avec DFS
uniquement
5470
impossible
impossible
5725
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
5
Nomadisme et Wifi
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).
6
Nomadisme et Wifi
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
Apple
Cisco Aironet
Agere (Lucent)
Linksys
Nokia
Compaq
Cabletron
Z-Com
Gemtek
SSID par défaut
Airport
tsunami
AirWave
linksys
Nokia WLAN
Compaq
RoamAbout
ftw-mc-2
defaut
7
Nomadisme et Wifi
Leichu
Lucent Technologies
D-Link
WLAN
WaveLAN Network
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
8
Nomadisme et Wifi
•
•
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
9
Nomadisme et Wifi
« 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.
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).
10
Nomadisme et Wifi
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
GRENOBLOIS
4.1.
PAR
LES
ETABLISSEMENTS
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-*
11
Nomadisme et Wifi
•
•
•
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
12
Nomadisme et Wifi
Principe d’architecture Wifi campus
Serveur Radius
Filtrage trafic
Wifi/VPN
Routeur inter-U
Vers le reste du monde
Concentrateur
VPN
Concentrateur
VPN
Routeur Etabliss. 1
Routeur Etabliss. 2
Serveur DHCP
Filtrage trafic
Wifi/VPN
Routeur Etabliss. i
Filtrage trafic
Wifi/VPN
Serveur DHCP
Réseaux Etablissement 1
Réseaux Etablissement i
VLAN Wifi Etablissement 1
Wifi
4.3.
VLAN Wifi Etablissement i
1
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.
13
Nomadisme et Wifi
Dans un premier temps, ce serveur sera celui utilisé pour identifier les utilisateurs du
CICG.
4.4.2. Serveurs DHCP
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
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
14
Nomadisme et Wifi
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
15
Nomadisme et Wifi
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).
16
Nomadisme et Wifi
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)
17
Nomadisme et Wifi
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/
18
Nomadisme et Wifi
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
19
Nomadisme et Wifi
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 RJ45 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
20
Nomadisme et Wifi
•
•
•
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
21
Nomadisme et Wifi
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
22
Nomadisme et Wifi
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/).
23
Nomadisme et Wifi
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
24
Nomadisme et Wifi
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.
25
Nomadisme et Wifi
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.
26
Nomadisme et Wifi
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 autocertification) 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.
27
Nomadisme et Wifi
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é
28
Nomadisme et Wifi
à 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.
29

Préconisation Grenet - Comité Réseau des Universités

Transcription

Documents pareils

Installation et configuration du client VPN IPSEC Shrewsoft pour

Nomadisme : Problématiques et Solutions

Routeur ProSafe Firewall sans fil 108 Mbp/s VPN 8

Routeur Firewall VPN SSL ProSafe SRX5308 La sécurité d`un

Téléchargez le dépliant

fiche technique top fun.pub

Série VM - Palo Alto Networks

FR_Global VPN DS A4_CS3.indd

CAP petite enfance - Greta de Grenoble

Gestion des PKI certificats, tokens et cartes à puce