Quel est les moins pire ?

Pierre LALET

01/08/2003 à 13:58

On peut avoir des bornes wifi mieux "sécurisée" maintenant ?

Une solution peut être de ne pas utiliser les systèmes de
cryptage/authentification (ou bien de les utiliser, sans se fonder sur
eux pour assurer la sécurité) qui viennent avec wifi, et de ne laisser
accéder les clients wifi qu'à une machine sur laquelle seul un service
de VPN tourne (IPSec par exemple), accompagné éventuellement de services
'surs' (ssh par exemple, ou page web de présentation).

Il se trouve que je travaille en stage sur le sujet des VPN, et que la
sécurisation des accès wifi en est une des applications. Mes notes de
stage sont disponibles en ligne (http://www.reaustage.u-bordeaux.fr/, le
concept est expliqué ici: http://www.reaustage.u-bordeaux.fr/wifi_vpn/).

Soyez indulgents, je débute. Les remarques sont évidemment les bienvenues.

pierre

--
Pierre LALET
Elève ingénieur -- ENSEIRB
-- http://www.enseirb.fr/~lalet
clé publique PGP : http://www.enseirb.fr/~lalet/pubkey

Thierry

01/08/2003 à 15:27

Bonjour,

Bertrand a écrit :

Oui, il y a le WPA. Mais bon, ajouter un cryptage type IPsec en dessous,
ca n'a jamais tué personne.

Des AP sont dispos en WPA ?

--
"Oh God I am the American dream
I do not think I'm too extreme
An' I'm a handsome son of a bitch
I'm gonna get a good job 'n' be real rich"

Cedric Blancher

01/08/2003 à 15:59

Dans sa prose, Thierry nous ecrivait :

Des AP sont dispos en WPA ?

Oui. C'est les drivers/firmwares de cartes qui semblent se faire plus
rares. C'est simplement parce qu'en fait, ce n'est pas franchement
nécessaire, vu le côté rustine de WPA.
Pour atteindre une sécurité décente, il faut un AP qui sache faire du
802.1x, et un RADIUS derrière qui sache gérer PEAP ou EAP-TLS. À partir de
là, on a une vraie phase d'authentification mutuelle, et une clé WEP qui
en est dérivée (i.e. la clé n'est pas la même pour tous). Et pour faire
tourner la clé, ben on impose une réauthentification régulière, qui sera
complètement transparente pour l'utilisateur.

En attendant 802.11i, ça le fait très bien.

--
BOFH excuse #202:

kernel panic: write-only-memory (/dev/wom0) capacity exceeded.

Bertrand

02/08/2003 à 17:29

Salut,

Oui. C'est les drivers/firmwares de cartes qui semblent se faire plus
rares. C'est simplement parce qu'en fait, ce n'est pas franchement
nécessaire, vu le côté rustine de WPA.

Je crois que les cartes Cisco gerent le WPA non ? En plus de leur truc
proprio, le LEAP.

Pour atteindre une sécurité décente, il faut un AP qui sache faire du
802.1x, et un RADIUS derrière qui sache gérer PEAP ou EAP-TLS. À
partir de là, on a une vraie phase d'authentification mutuelle, et une
clé WEP qui en est dérivée (i.e. la clé n'est pas la même pour
tous). Et pour faire tourner la clé, ben on impose une
réauthentification régulière, qui sera complètement transparente
pour l'utilisateur.

=> C'est le cas de l'AP NetGear ME103 (gestion de RADIUS/EAP-TLS). Je vais
en recevoir un lundi, je pourrais voir ce que ca donne; si un feedback
interesse des gens, "laissez moi un message".

@+
Bertrand

Bertrand

02/08/2003 à 17:29

Salut,

Une solution peut être de ne pas utiliser les systèmes de
cryptage/authentification (ou bien de les utiliser, sans se fonder sur
eux pour assurer la sécurité) qui viennent avec wifi, et de ne laisser
accéder les clients wifi qu'à une machine sur laquelle seul un service
de VPN tourne (IPSec par exemple), accompagné éventuellement de
services 'surs' (ssh par exemple, ou page web de présentation).

Ton VPN, avec toutes les couches de cryptage et d'auth que tu pourras
ajouter, il n'empechera personne de venir sur l'AP. Et une personne sur
l'AP = une personne qui a accés au reseau. Meme si elle ne pourra
qu'acceder au serveur VPN, il se pourrait bien que celui ci soit
vulnerable a telle ou telle attaque.
Il faut donc d'aprés moi empecher a tout prix que l'on puisse venir sur
l'AP, et pour cela, il y a plusieurs choses a faire: - Restriction par
adresse MAC; difficilement applicable chez vous, trop lourd a gerer -
Utilisation du WEP... ce qui empeche la connection au reseau par le mec
qui passe par là.

Il se trouve que je travaille en stage sur le sujet des VPN, et que la
sécurisation des accès wifi en est une des applications. Mes notes de
stage sont disponibles en ligne (http://www.reaustage.u-bordeaux.fr/, le
concept est expliqué ici:
http://www.reaustage.u-bordeaux.fr/wifi_vpn/). Soyez indulgents, je
débute. Les remarques sont évidemment les bienvenues.

Si je peux me permettre de formuler une ou deux remarques : (les remarques
sur mes remarques sont les bienvenues egalement :o))

- http://www.reaustage.u-bordeaux.fr/wifi_vpn/#SECTION00021000000000000000
Ici, pourquoi ne pas donner l'accés par Internet d'abord au serveur VPN,
et forcer le passage par celui-ci pour se connecter au REAUMUR ? Plutot
que de donner accés au REAUMUR, passer par le VPN, et revenir dans le
REAUMUR ?

Ce que je ferai:
- Le serveur VPN aurait 3 pattes; il recevrait sur l'une les connections
Wifi, sur l'autre les connections via Internet. Enfin la 3eme patte, la
"sortie", irait vers le REAUMUR. Et par l'intermediaire de celui ci, les
clients auraient accés au reseau filaire. Ce serait la seule machine
connectée au reseaux hostiles. Il doit donc y avoir une bonne couche de
filtrage dessus. Plus du filtrage complementaire dans le REAUMUR qui
filtre ce qui vient de cette machine, celle ci ayant eventuellement pu
avoir ete compromise (empecher qu'elle fasse vraiment n'importe quoi,
c'est tout).

Le serveur VPN ferait alors l'authentification et une premiere partie du
routage des paquets, puis c'est le REAUMUR qui dispatcherait les paquets
dans les bons reseaux filaires.

- http://www.reaustage.u-bordeaux.fr/wifi_vpn/#SECTION00041000000000000000
(dans Securiser la machine cliente)
On y lit:
"Il serait souhaitable de sécuriser par un logiciel permettant de filtrer
les paquets (certains clients VPN proposent ce genre de choses par
défaut, il faudra étudier cette question) sur la machine cliente"

Heu, du filtrage sur la machine cliente ? Ca securise rien (vraiment
rien), et puis il n'y a aucun filtrage que l'on ne puisse pas faire sur le
serveur VPN (si?).

Sinon, il y a quand meme le probleme des responsabilités en cas de
"grosse betise". On doit imperativement logguer a qui etait attribuée
telle ou telle adresse IP a telle ou telle heure, pour avoir un minimum de
tracabilité. Il faut donc connaitre l'identité des invités avant de
leur donner accés a quoi que ce soit. Comme ca si betise il y a, on saura
a qui demander des comptes (meme si il vaut mieux eviter qu'il y ait des
betises de faites, ca peut arriver).

De plus, etant donné que l'on cherche a avoir de la tracabilité, il faut
que l'on puisse avoir confiance absolue en la/les personnes qui
etablissent les comptes invités. Et là, plus on donne de droits de
creation, moins on peut avoir confiance sur l'authenticité des infos
fournies. Donc donner le droit a "tout les gens des labos" de creer des
users, c'est peut etre pas une bonne idée.

Pourquoi ne pas confier cette tache a 1 ou deux personnes bien definies,
qui seraient clairement responsables en cas de probleme si on ne peut pas
trouver d'infos correctes dans la base des utilisateurs ?
Il ne faut pas qu'un invité en situation irreguliere puisse se connecter
plus facilement que quelqu'un qui a suivi la procedure ! Là il suffit, si
je comprend bien, de se rammener, de demander a n'importe qui du labo un
compte en invoquant n'importe quel pretexte plausible, et hop :) (et si
ca marche pas, on demande a quelqu'un d'autre, jusqu'a ce qu'on trouve
quelqu'un qui accepte)
Et puis il faut donner une limite a l'irregularité: a partir d'un certain
point, on dit "non" a l'accés au reseau. Ca sert a rien d'avoir une
procedure si c'est pour en faire une autre en cas de non respect de la
premiere. Autant a ce moment là revoir directement la premiere, qui est
peut etre trop complexe.

Voila pour mes deux euros...

@+
Bertrand

Salut,

Une solution peut être de ne pas utiliser les systèmes de
cryptage/authentification (ou bien de les utiliser, sans se fonder sur
eux pour assurer la sécurité) qui viennent avec wifi, et de ne laisser
accéder les clients wifi qu'à une machine sur laquelle seul un service
de VPN tourne (IPSec par exemple), accompagné éventuellement de
services 'surs' (ssh par exemple, ou page web de présentation).

Ton VPN, avec toutes les couches de cryptage et d'auth que tu pourras
ajouter, il n'empechera personne de venir sur l'AP. Et une personne sur
l'AP = une personne qui a accés au reseau. Meme si elle ne pourra
qu'acceder au serveur VPN, il se pourrait bien que celui ci soit
vulnerable a telle ou telle attaque.
Il faut donc d'aprés moi empecher a tout prix que l'on puisse venir sur
l'AP, et pour cela, il y a plusieurs choses a faire: - Restriction par
adresse MAC; difficilement applicable chez vous, trop lourd a gerer -
Utilisation du WEP... ce qui empeche la connection au reseau par le mec
qui passe par là.

Il se trouve que je travaille en stage sur le sujet des VPN, et que la
sécurisation des accès wifi en est une des applications. Mes notes de
stage sont disponibles en ligne (http://www.reaustage.u-bordeaux.fr/, le
concept est expliqué ici:
http://www.reaustage.u-bordeaux.fr/wifi_vpn/). Soyez indulgents, je
débute. Les remarques sont évidemment les bienvenues.

Si je peux me permettre de formuler une ou deux remarques : (les remarques
sur mes remarques sont les bienvenues egalement :o))

- http://www.reaustage.u-bordeaux.fr/wifi_vpn/#SECTION00021000000000000000
Ici, pourquoi ne pas donner l'accés par Internet d'abord au serveur VPN,
et forcer le passage par celui-ci pour se connecter au REAUMUR ? Plutot
que de donner accés au REAUMUR, passer par le VPN, et revenir dans le
REAUMUR ?

Ce que je ferai:
- Le serveur VPN aurait 3 pattes; il recevrait sur l'une les connections
Wifi, sur l'autre les connections via Internet. Enfin la 3eme patte, la
"sortie", irait vers le REAUMUR. Et par l'intermediaire de celui ci, les
clients auraient accés au reseau filaire. Ce serait la seule machine
connectée au reseaux hostiles. Il doit donc y avoir une bonne couche de
filtrage dessus. Plus du filtrage complementaire dans le REAUMUR qui
filtre ce qui vient de cette machine, celle ci ayant eventuellement pu
avoir ete compromise (empecher qu'elle fasse vraiment n'importe quoi,
c'est tout).

Le serveur VPN ferait alors l'authentification et une premiere partie du
routage des paquets, puis c'est le REAUMUR qui dispatcherait les paquets
dans les bons reseaux filaires.

- http://www.reaustage.u-bordeaux.fr/wifi_vpn/#SECTION00041000000000000000
(dans Securiser la machine cliente)
On y lit:
"Il serait souhaitable de sécuriser par un logiciel permettant de filtrer
les paquets (certains clients VPN proposent ce genre de choses par
défaut, il faudra étudier cette question) sur la machine cliente"

Heu, du filtrage sur la machine cliente ? Ca securise rien (vraiment
rien), et puis il n'y a aucun filtrage que l'on ne puisse pas faire sur le
serveur VPN (si?).

Sinon, il y a quand meme le probleme des responsabilités en cas de
"grosse betise". On doit imperativement logguer a qui etait attribuée
telle ou telle adresse IP a telle ou telle heure, pour avoir un minimum de
tracabilité. Il faut donc connaitre l'identité des invités avant de
leur donner accés a quoi que ce soit. Comme ca si betise il y a, on saura
a qui demander des comptes (meme si il vaut mieux eviter qu'il y ait des
betises de faites, ca peut arriver).

De plus, etant donné que l'on cherche a avoir de la tracabilité, il faut
que l'on puisse avoir confiance absolue en la/les personnes qui
etablissent les comptes invités. Et là, plus on donne de droits de
creation, moins on peut avoir confiance sur l'authenticité des infos
fournies. Donc donner le droit a "tout les gens des labos" de creer des
users, c'est peut etre pas une bonne idée.

Pourquoi ne pas confier cette tache a 1 ou deux personnes bien definies,
qui seraient clairement responsables en cas de probleme si on ne peut pas
trouver d'infos correctes dans la base des utilisateurs ?
Il ne faut pas qu'un invité en situation irreguliere puisse se connecter
plus facilement que quelqu'un qui a suivi la procedure ! Là il suffit, si
je comprend bien, de se rammener, de demander a n'importe qui du labo un
compte en invoquant n'importe quel pretexte plausible, et hop :) (et si
ca marche pas, on demande a quelqu'un d'autre, jusqu'a ce qu'on trouve
quelqu'un qui accepte)
Et puis il faut donner une limite a l'irregularité: a partir d'un certain
point, on dit "non" a l'accés au reseau. Ca sert a rien d'avoir une
procedure si c'est pour en faire une autre en cas de non respect de la
premiere. Autant a ce moment là revoir directement la premiere, qui est
peut etre trop complexe.

Voila pour mes deux euros...

@+
Bertrand

Vous avez filtré cet utilisateur ! Consultez son message

Salut,

Une solution peut être de ne pas utiliser les systèmes de
cryptage/authentification (ou bien de les utiliser, sans se fonder sur
eux pour assurer la sécurité) qui viennent avec wifi, et de ne laisser
accéder les clients wifi qu'à une machine sur laquelle seul un service
de VPN tourne (IPSec par exemple), accompagné éventuellement de
services 'surs' (ssh par exemple, ou page web de présentation).

Ton VPN, avec toutes les couches de cryptage et d'auth que tu pourras
ajouter, il n'empechera personne de venir sur l'AP. Et une personne sur
l'AP = une personne qui a accés au reseau. Meme si elle ne pourra
qu'acceder au serveur VPN, il se pourrait bien que celui ci soit
vulnerable a telle ou telle attaque.
Il faut donc d'aprés moi empecher a tout prix que l'on puisse venir sur
l'AP, et pour cela, il y a plusieurs choses a faire: - Restriction par
adresse MAC; difficilement applicable chez vous, trop lourd a gerer -
Utilisation du WEP... ce qui empeche la connection au reseau par le mec
qui passe par là.

Il se trouve que je travaille en stage sur le sujet des VPN, et que la
sécurisation des accès wifi en est une des applications. Mes notes de
stage sont disponibles en ligne (http://www.reaustage.u-bordeaux.fr/, le
concept est expliqué ici:
http://www.reaustage.u-bordeaux.fr/wifi_vpn/). Soyez indulgents, je
débute. Les remarques sont évidemment les bienvenues.

Si je peux me permettre de formuler une ou deux remarques : (les remarques
sur mes remarques sont les bienvenues egalement :o))

- http://www.reaustage.u-bordeaux.fr/wifi_vpn/#SECTION00021000000000000000
Ici, pourquoi ne pas donner l'accés par Internet d'abord au serveur VPN,
et forcer le passage par celui-ci pour se connecter au REAUMUR ? Plutot
que de donner accés au REAUMUR, passer par le VPN, et revenir dans le
REAUMUR ?

Ce que je ferai:
- Le serveur VPN aurait 3 pattes; il recevrait sur l'une les connections
Wifi, sur l'autre les connections via Internet. Enfin la 3eme patte, la
"sortie", irait vers le REAUMUR. Et par l'intermediaire de celui ci, les
clients auraient accés au reseau filaire. Ce serait la seule machine
connectée au reseaux hostiles. Il doit donc y avoir une bonne couche de
filtrage dessus. Plus du filtrage complementaire dans le REAUMUR qui
filtre ce qui vient de cette machine, celle ci ayant eventuellement pu
avoir ete compromise (empecher qu'elle fasse vraiment n'importe quoi,
c'est tout).

Le serveur VPN ferait alors l'authentification et une premiere partie du
routage des paquets, puis c'est le REAUMUR qui dispatcherait les paquets
dans les bons reseaux filaires.

- http://www.reaustage.u-bordeaux.fr/wifi_vpn/#SECTION00041000000000000000
(dans Securiser la machine cliente)
On y lit:
"Il serait souhaitable de sécuriser par un logiciel permettant de filtrer
les paquets (certains clients VPN proposent ce genre de choses par
défaut, il faudra étudier cette question) sur la machine cliente"

Heu, du filtrage sur la machine cliente ? Ca securise rien (vraiment
rien), et puis il n'y a aucun filtrage que l'on ne puisse pas faire sur le
serveur VPN (si?).

Sinon, il y a quand meme le probleme des responsabilités en cas de
"grosse betise". On doit imperativement logguer a qui etait attribuée
telle ou telle adresse IP a telle ou telle heure, pour avoir un minimum de
tracabilité. Il faut donc connaitre l'identité des invités avant de
leur donner accés a quoi que ce soit. Comme ca si betise il y a, on saura
a qui demander des comptes (meme si il vaut mieux eviter qu'il y ait des
betises de faites, ca peut arriver).

De plus, etant donné que l'on cherche a avoir de la tracabilité, il faut
que l'on puisse avoir confiance absolue en la/les personnes qui
etablissent les comptes invités. Et là, plus on donne de droits de
creation, moins on peut avoir confiance sur l'authenticité des infos
fournies. Donc donner le droit a "tout les gens des labos" de creer des
users, c'est peut etre pas une bonne idée.

Pourquoi ne pas confier cette tache a 1 ou deux personnes bien definies,
qui seraient clairement responsables en cas de probleme si on ne peut pas
trouver d'infos correctes dans la base des utilisateurs ?
Il ne faut pas qu'un invité en situation irreguliere puisse se connecter
plus facilement que quelqu'un qui a suivi la procedure ! Là il suffit, si
je comprend bien, de se rammener, de demander a n'importe qui du labo un
compte en invoquant n'importe quel pretexte plausible, et hop :) (et si
ca marche pas, on demande a quelqu'un d'autre, jusqu'a ce qu'on trouve
quelqu'un qui accepte)
Et puis il faut donner une limite a l'irregularité: a partir d'un certain
point, on dit "non" a l'accés au reseau. Ca sert a rien d'avoir une
procedure si c'est pour en faire une autre en cas de non respect de la
premiere. Autant a ce moment là revoir directement la premiere, qui est
peut etre trop complexe.

Voila pour mes deux euros...

@+
Bertrand

Bertrand

04/08/2003 à 11:12

Salut,

Il se trouve que je travaille en stage sur le sujet des VPN, et que la
sécurisation des accès wifi en est une des applications. Mes notes de
stage sont disponibles en ligne (http://www.reaustage.u-bordeaux.fr/, le
concept est expliqué ici: http://www.reaustage.u-bordeaux.fr/wifi_vpn/).

Sinon, un projet qui pourrait etre trés trés interessant dans votre cas:
http://nocat.net/

C'est un projet qui consiste a filtrer le traffic en provenance des
reseaux sans fils, et a demander aux utilisateurs de s'authentifier avant
de pouvoir faire quoi que ce soit (ils sont redirigés vers une page de
login si ils ne sont pas authentifiés).

Le principe a l'air cool, mais j'ai pas testé.

@+
Bertrand

Cedric Blancher

04/08/2003 à 11:16

Dans sa prose, Bertrand nous ecrivait :

Sinon, un projet qui pourrait etre trés trés interessant dans votre cas:
http://nocat.net/
C'est un projet qui consiste a filtrer le traffic en provenance des
reseaux sans fils, et a demander aux utilisateurs de s'authentifier avant
de pouvoir faire quoi que ce soit (ils sont redirigés vers une page de
login si ils ne sont pas authentifiés).

Ça a l'air sympa pour les HotSpot. C'est d'ailleurs spécifiquement
développé pour ;) Mais dans le cas où on maîtrise le parc des machines qui
viennent se connecter, une authentification 802.1x me semble nettement
plus souple et efficace.

--
À l'unanimité de moi-même, je suis d'accord.
-+- SB in Debian-french: "le debian-french guru a dit" -+-

Cedric Blancher

04/08/2003 à 15:39

Dans sa prose, Nicolas Jombart nous ecrivait :

-> Cedric Blancher :
Ça a l'air sympa pour les HotSpot. C'est d'ailleurs spécifiquement
développé pour ;) Mais dans le cas où on maîtrise le parc des
machines qui viennent se connecter, une authentification 802.1x me
semble nettement plus souple et efficace.
Mais l'avantage de l'usurpation HTTP c'est que ça ne demande aucune

installation ou configuration particulière pour le client. Il suffit
juste d'un navigateur et de laisser une petite fenêtre sur le coté.

C'est pour cela que je précisais "dans le cas où on maîtrise le parc"...
Dans ce cas là, tu peux par exemple coupler l'authentification au réseau à
l'authentification au domaine : le mec se logue, et ses identifiants
servent aussi bien au domaine qu'à EAP. Etc.

--
BOFH excuse #289:

Interference between the keyboard and the chair.

Bertrand

04/08/2003 à 15:45

Salut,

Cela pose le même problème que si on donne simplement accès à un
concentrateur VPN (i.e., laisser accéder à une machine qui peut avoir
un service qui a une faille), non ?

Absolument, mais j'ai reflechi un peu entre temps, et j'ai pu mettre ma
parano en veilleuse, ou tout du moins imaginer plusieurs solutions a ton
probleme. Aprés, il faut choisir la bonne..

Dire "il faut absolument mettre le WEP", c'est pas bon pour vous. En
effet, soit on a une auth type clef partagée, et là donner la meme clef
a plusieurs dizaines/centaines d'utilisateurs n'est pas trés malin. En
effet, soit on ne la change jamais et elle va se retrouver de partout sur
le web, ou alors le bouche a oreille fera que a 100km a la ronde on aura
la clef, soit on la changera regulierement et ce sera un bazar monstrueux,
avec des usagers qui ralent "pourquoi ca marche plus ?" "t'as mis la
nouvelle clef ?" "pourquoi, yen a une nouvele ??" etc. Donc, solution clef
partagée = a eviter.

Par contre l'EAP-TLS peut etre une bonne solution, voir ci aprés.

L'avantage de NoCat par rapport au VPN, c'est que il est specifiquement
etudié pour un usage type HotSpot, avec auth SSL, et une certaine
facilité d'utilisation (on peut afficher les instructions de connection
directement sur l'ecran de l'utilisateur qui vient s'attacher sur l'AP).

L'inconvenient de NoCat par rapport au VPN (sous reserve que mon
interpretation du fonctionnement de NoCat soit correcte), c'est que le
traffic radio n'est pas crypté. Et ca, c'est pas bon. Du tout.

Si le niveau en info des utilisateurs le permet, il serait preferable dans
votre cas d'utiliser un VPN, avec en plus une auth EAP-TLS. Comme ca, on
peut pas sniffer ce qu'envoie le voisin, il n'y a pas de cassage de clef
possible: on n'a donc une bonne securité coté radio, et on garde une
certaine souplesse puisque on peut router comme on veut avec le routeur.
(on doit pouvoir modifier les regles de routage pour le client en fonction
de l'auth fournie au serveur Radius, mais alors comment ?)

Un truc qui ressemblerait a ce que je verrai dans ton cas, et qui ne pose
aucun probleme de securité:
(police a espacement fixe)

Serveur RADIUS
^
|
+-------+--------+
| | +-------+
Client Wifi 1 -----+-> Access Point -------> Rtr -----+---> | LAN 1 |
Client Wifi 2 -----| ^ | +-------+
Client Wifi 3 -----/ | |
+----+-----+ | +-------+
| Internet | +---> | LAN 2 |
+--+-+-+---+ +-------+
/ |
/ |
Client Internet 1 - | - Client Internet 3
|
Client Internet 2

Rtr = routeur, serveur VPN, serveur DHCP.

Quand un client Wifi se connecte, il le fait via l'AP. L'AP gere l'auth
avec le serveur RADIUS, celui ci informe Rtr qu'un nouveau client est
arrivé. Le serveur DHCP attribue une adresse IP a ce client, et met en
place les regles de routage/firewall correspondant a sa classe
(invité/labo). Ainsi pas besoin de VPN, on se sert uniquement de la
securité de l'AP, et du serveur RADIUS comme source d'infos sur les
utilisateurs en ligne.

Quand un client Internet se connecte, il crée un VPN sur le routeur (auth
par le serveur Radius, puisqu'on gere toute l'auth avec). Une fois l'auth
effectuée, on attribue toujours par DHCP une adresse au client, et on
choisit les regles de filtrage en fonction de la classe de ce client...
(je sais pas, on peut imaginer un systeme type classe 0 = on a accés a
tout, classe 1 = labo seulement, classe 2 = invité)

Dans ce scneario, il n'y a rien en trop, et rien de manquant pour avoir
une bonne securité, une bonne facilité d'utilisaiton. Par contre, je dis
pas que ca va etre facile a installer ;)

Ca c'etait si on a des utilisateurs qui sont prets a passer quelques
minutes a configurer l'auth.

Si ils n'en ont pas le niveau ou pas l'envie, on peut utiliser NoCat,
autoriser seulement l'accés au Web avec, et rendre dispo la creation
d'un tunnel VPN qui donnera accés a plus ou - de privileges en fonction
de la classe de l'utilisateur. C'est "peut etre" plus simple mais la
securité me semble moindre, puisque le traffic Web sera toujours en
clair (et avec les webmails, ca promet des logins/pass a profusion dans
kismet)

Remarque; tout serait plus simple a gerer si il n'y avait pas plusieurs
classes de clients a gerer, avec des options d'accés reseau differentes
pour chacunes d'elles. Mais bon, "si cahier des charges il y aura, le
respecter tu devras."

@+
Bertrand

Salut,

Cela pose le même problème que si on donne simplement accès à un
concentrateur VPN (i.e., laisser accéder à une machine qui peut avoir
un service qui a une faille), non ?

Absolument, mais j'ai reflechi un peu entre temps, et j'ai pu mettre ma
parano en veilleuse, ou tout du moins imaginer plusieurs solutions a ton
probleme. Aprés, il faut choisir la bonne..

Dire "il faut absolument mettre le WEP", c'est pas bon pour vous. En
effet, soit on a une auth type clef partagée, et là donner la meme clef
a plusieurs dizaines/centaines d'utilisateurs n'est pas trés malin. En
effet, soit on ne la change jamais et elle va se retrouver de partout sur
le web, ou alors le bouche a oreille fera que a 100km a la ronde on aura
la clef, soit on la changera regulierement et ce sera un bazar monstrueux,
avec des usagers qui ralent "pourquoi ca marche plus ?" "t'as mis la
nouvelle clef ?" "pourquoi, yen a une nouvele ??" etc. Donc, solution clef
partagée = a eviter.

Par contre l'EAP-TLS peut etre une bonne solution, voir ci aprés.

L'avantage de NoCat par rapport au VPN, c'est que il est specifiquement
etudié pour un usage type HotSpot, avec auth SSL, et une certaine
facilité d'utilisation (on peut afficher les instructions de connection
directement sur l'ecran de l'utilisateur qui vient s'attacher sur l'AP).

L'inconvenient de NoCat par rapport au VPN (sous reserve que mon
interpretation du fonctionnement de NoCat soit correcte), c'est que le
traffic radio n'est pas crypté. Et ca, c'est pas bon. Du tout.

Si le niveau en info des utilisateurs le permet, il serait preferable dans
votre cas d'utiliser un VPN, avec en plus une auth EAP-TLS. Comme ca, on
peut pas sniffer ce qu'envoie le voisin, il n'y a pas de cassage de clef
possible: on n'a donc une bonne securité coté radio, et on garde une
certaine souplesse puisque on peut router comme on veut avec le routeur.
(on doit pouvoir modifier les regles de routage pour le client en fonction
de l'auth fournie au serveur Radius, mais alors comment ?)

Un truc qui ressemblerait a ce que je verrai dans ton cas, et qui ne pose
aucun probleme de securité:
(police a espacement fixe)

Serveur RADIUS
^
|
+-------+--------+
| | +-------+
Client Wifi 1 -----+-> Access Point -------> Rtr -----+---> | LAN 1 |
Client Wifi 2 -----| ^ | +-------+
Client Wifi 3 -----/ | |
+----+-----+ | +-------+
| Internet | +---> | LAN 2 |
+--+-+-+---+ +-------+
/ |
/ |
Client Internet 1 - | - Client Internet 3
|
Client Internet 2

Rtr = routeur, serveur VPN, serveur DHCP.

Quand un client Wifi se connecte, il le fait via l'AP. L'AP gere l'auth
avec le serveur RADIUS, celui ci informe Rtr qu'un nouveau client est
arrivé. Le serveur DHCP attribue une adresse IP a ce client, et met en
place les regles de routage/firewall correspondant a sa classe
(invité/labo). Ainsi pas besoin de VPN, on se sert uniquement de la
securité de l'AP, et du serveur RADIUS comme source d'infos sur les
utilisateurs en ligne.

Quand un client Internet se connecte, il crée un VPN sur le routeur (auth
par le serveur Radius, puisqu'on gere toute l'auth avec). Une fois l'auth
effectuée, on attribue toujours par DHCP une adresse au client, et on
choisit les regles de filtrage en fonction de la classe de ce client...
(je sais pas, on peut imaginer un systeme type classe 0 = on a accés a
tout, classe 1 = labo seulement, classe 2 = invité)

Dans ce scneario, il n'y a rien en trop, et rien de manquant pour avoir
une bonne securité, une bonne facilité d'utilisaiton. Par contre, je dis
pas que ca va etre facile a installer ;)

Ca c'etait si on a des utilisateurs qui sont prets a passer quelques
minutes a configurer l'auth.

Si ils n'en ont pas le niveau ou pas l'envie, on peut utiliser NoCat,
autoriser seulement l'accés au Web avec, et rendre dispo la creation
d'un tunnel VPN qui donnera accés a plus ou - de privileges en fonction
de la classe de l'utilisateur. C'est "peut etre" plus simple mais la
securité me semble moindre, puisque le traffic Web sera toujours en
clair (et avec les webmails, ca promet des logins/pass a profusion dans
kismet)

Remarque; tout serait plus simple a gerer si il n'y avait pas plusieurs
classes de clients a gerer, avec des options d'accés reseau differentes
pour chacunes d'elles. Mais bon, "si cahier des charges il y aura, le
respecter tu devras."

@+
Bertrand

Vous avez filtré cet utilisateur ! Consultez son message

Salut,

Cela pose le même problème que si on donne simplement accès à un
concentrateur VPN (i.e., laisser accéder à une machine qui peut avoir
un service qui a une faille), non ?

Absolument, mais j'ai reflechi un peu entre temps, et j'ai pu mettre ma
parano en veilleuse, ou tout du moins imaginer plusieurs solutions a ton
probleme. Aprés, il faut choisir la bonne..

Dire "il faut absolument mettre le WEP", c'est pas bon pour vous. En
effet, soit on a une auth type clef partagée, et là donner la meme clef
a plusieurs dizaines/centaines d'utilisateurs n'est pas trés malin. En
effet, soit on ne la change jamais et elle va se retrouver de partout sur
le web, ou alors le bouche a oreille fera que a 100km a la ronde on aura
la clef, soit on la changera regulierement et ce sera un bazar monstrueux,
avec des usagers qui ralent "pourquoi ca marche plus ?" "t'as mis la
nouvelle clef ?" "pourquoi, yen a une nouvele ??" etc. Donc, solution clef
partagée = a eviter.

Par contre l'EAP-TLS peut etre une bonne solution, voir ci aprés.

L'avantage de NoCat par rapport au VPN, c'est que il est specifiquement
etudié pour un usage type HotSpot, avec auth SSL, et une certaine
facilité d'utilisation (on peut afficher les instructions de connection
directement sur l'ecran de l'utilisateur qui vient s'attacher sur l'AP).

L'inconvenient de NoCat par rapport au VPN (sous reserve que mon
interpretation du fonctionnement de NoCat soit correcte), c'est que le
traffic radio n'est pas crypté. Et ca, c'est pas bon. Du tout.

Si le niveau en info des utilisateurs le permet, il serait preferable dans
votre cas d'utiliser un VPN, avec en plus une auth EAP-TLS. Comme ca, on
peut pas sniffer ce qu'envoie le voisin, il n'y a pas de cassage de clef
possible: on n'a donc une bonne securité coté radio, et on garde une
certaine souplesse puisque on peut router comme on veut avec le routeur.
(on doit pouvoir modifier les regles de routage pour le client en fonction
de l'auth fournie au serveur Radius, mais alors comment ?)

Un truc qui ressemblerait a ce que je verrai dans ton cas, et qui ne pose
aucun probleme de securité:
(police a espacement fixe)

Serveur RADIUS
^
|
+-------+--------+
| | +-------+
Client Wifi 1 -----+-> Access Point -------> Rtr -----+---> | LAN 1 |
Client Wifi 2 -----| ^ | +-------+
Client Wifi 3 -----/ | |
+----+-----+ | +-------+
| Internet | +---> | LAN 2 |
+--+-+-+---+ +-------+
/ |
/ |
Client Internet 1 - | - Client Internet 3
|
Client Internet 2

Rtr = routeur, serveur VPN, serveur DHCP.

Quand un client Wifi se connecte, il le fait via l'AP. L'AP gere l'auth
avec le serveur RADIUS, celui ci informe Rtr qu'un nouveau client est
arrivé. Le serveur DHCP attribue une adresse IP a ce client, et met en
place les regles de routage/firewall correspondant a sa classe
(invité/labo). Ainsi pas besoin de VPN, on se sert uniquement de la
securité de l'AP, et du serveur RADIUS comme source d'infos sur les
utilisateurs en ligne.

Quand un client Internet se connecte, il crée un VPN sur le routeur (auth
par le serveur Radius, puisqu'on gere toute l'auth avec). Une fois l'auth
effectuée, on attribue toujours par DHCP une adresse au client, et on
choisit les regles de filtrage en fonction de la classe de ce client...
(je sais pas, on peut imaginer un systeme type classe 0 = on a accés a
tout, classe 1 = labo seulement, classe 2 = invité)

Dans ce scneario, il n'y a rien en trop, et rien de manquant pour avoir
une bonne securité, une bonne facilité d'utilisaiton. Par contre, je dis
pas que ca va etre facile a installer ;)

Ca c'etait si on a des utilisateurs qui sont prets a passer quelques
minutes a configurer l'auth.

Si ils n'en ont pas le niveau ou pas l'envie, on peut utiliser NoCat,
autoriser seulement l'accés au Web avec, et rendre dispo la creation
d'un tunnel VPN qui donnera accés a plus ou - de privileges en fonction
de la classe de l'utilisateur. C'est "peut etre" plus simple mais la
securité me semble moindre, puisque le traffic Web sera toujours en
clair (et avec les webmails, ca promet des logins/pass a profusion dans
kismet)

Remarque; tout serait plus simple a gerer si il n'y avait pas plusieurs
classes de clients a gerer, avec des options d'accés reseau differentes
pour chacunes d'elles. Mais bon, "si cahier des charges il y aura, le
respecter tu devras."

@+
Bertrand

Sylvain

05/08/2003 à 11:02

Sylvain a écrit:

- courant porteur

La portée d'une solution courant porteur est limitée (150m) et le
cryptage en DES 56 bits.

Ce genre d'engins, ça marche ? avec quelle sécurité ?

http://www.dslvalley.com/dossiers/powerline/powerline1.html
http://www.ldlc.fr/fiche/PB00016275.html

ça me parait plus sur que de wifi, non ?
parce qu'en wifi, il suffit de se garer en bas de la rue pour
écouter le réseau (il faut aussi décrypter), alors que dans une
solution courant porteur, il faut habiter dans le coin (300 m)
pour pouvoir écouter (et décrypter).

Je dis une bétise ?

Quel est les moins pire ?

10 réponses

Veuillez sélectionner un problème