Alors qu'on propose le 802.1x comme alternative sure au WEP pour la
protection des reseaux sans file type WiFi, il se trouve que ce standard
est vulnerable a certaines attaques a cause d'une mauvaise implementation
du protocole Radius dans la majorité des Access Points, etc (enfin, c'est
ce que j'ai compris):
http://home.jwu.edu/jwright/radius_vuln_00.txt
Qui dit mieux que le 802.1x ? Ca devient bien lourd a la fin... le WiFi
semble decidemment difficile a bien securiser...
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Thierry
Bonjour,
Bertrand a écrit :
Qui dit mieux que le 802.1x ? Ca devient bien lourd a la fin... le WiFi semble decidemment difficile a bien securiser...
Faut quand même pouvoir sniffer le traffic entre la borne et le serveur radius... Suffit donc d'empecher ce sniff (lien direct entre l'AP et le serveur RADIUS) pour contrer cette attaque.
-- « Always look at the bright side of the life... »
Bonjour,
Bertrand a écrit :
Qui dit mieux que le 802.1x ? Ca devient bien lourd a la fin... le WiFi
semble decidemment difficile a bien securiser...
Faut quand même pouvoir sniffer le traffic entre la borne et le serveur
radius... Suffit donc d'empecher ce sniff (lien direct entre l'AP et le
serveur RADIUS) pour contrer cette attaque.
--
« Always look at the bright side of the life... »
Qui dit mieux que le 802.1x ? Ca devient bien lourd a la fin... le WiFi semble decidemment difficile a bien securiser...
Faut quand même pouvoir sniffer le traffic entre la borne et le serveur radius... Suffit donc d'empecher ce sniff (lien direct entre l'AP et le serveur RADIUS) pour contrer cette attaque.
-- « Always look at the bright side of the life... »
T0t0
"Thierry" wrote in message news:
Faut quand même pouvoir sniffer le traffic entre la borne et le serveur radius... Suffit donc d'empecher ce sniff (lien direct entre l'AP et le serveur RADIUS) pour contrer cette attaque.
Oui, mais dès que ton réseau est assez grand et que tes bornes sont disposées un peu partout à travers le monde, ca devient un peu lourd d'avoir un VLAN dédié distribué...
IPsec rulez :-)
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
"Thierry" <yarglah@com.invalid> wrote in message
news:XnF95397B6CD9831pouletetcetc@212.27.42.71
Faut quand même pouvoir sniffer le traffic entre la borne et le serveur
radius... Suffit donc d'empecher ce sniff (lien direct entre l'AP et le
serveur RADIUS) pour contrer cette attaque.
Oui, mais dès que ton réseau est assez grand et que tes bornes sont
disposées un peu partout à travers le monde, ca devient un peu lourd
d'avoir un VLAN dédié distribué...
IPsec rulez :-)
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
Faut quand même pouvoir sniffer le traffic entre la borne et le serveur radius... Suffit donc d'empecher ce sniff (lien direct entre l'AP et le serveur RADIUS) pour contrer cette attaque.
Oui, mais dès que ton réseau est assez grand et que tes bornes sont disposées un peu partout à travers le monde, ca devient un peu lourd d'avoir un VLAN dédié distribué...
IPsec rulez :-)
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
Bertrand
Salut,
Oui, mais dès que ton réseau est assez grand et que tes bornes sont disposées un peu partout à travers le monde, ca devient un peu lourd d'avoir un VLAN dédié distribué...
Oui.
IPsec rulez :-)
Heu.... ca c'est comme quand dans le draft ils nous sortent: | If encryption must be done at the AP, the AP must communicate with | Authentication Server (RADIUS Server) through IPSec.
Ben voyons ! Bien sur ! Et puis faut aussi mettre un reseau quantique entre l'AP et le serveur RADIUS ! Comme ca on ne peut pas sniffer le traffic !
J'ai pas vu un seul access point qui gerait l'IPsec... et je trouve que faire tourner Radius en IPsec est une rustine; il vaudrait mieux securiser Radius et basta. Au lieu d'utiliser un shared secret fixe on pourrait par exemple utiliser un systeme type parametres de Diffie-Hellman.
@+ Bertrand
Salut,
Oui, mais dès que ton réseau est assez grand et que tes bornes sont
disposées un peu partout à travers le monde, ca devient un peu lourd
d'avoir un VLAN dédié distribué...
Oui.
IPsec rulez :-)
Heu.... ca c'est comme quand dans le draft ils nous sortent:
| If encryption must be done at the AP, the AP must communicate with
| Authentication Server (RADIUS Server) through IPSec.
Ben voyons ! Bien sur ! Et puis faut aussi mettre un reseau quantique
entre l'AP et le serveur RADIUS ! Comme ca on ne peut pas sniffer le
traffic !
J'ai pas vu un seul access point qui gerait l'IPsec... et je trouve que
faire tourner Radius en IPsec est une rustine; il vaudrait mieux securiser
Radius et basta. Au lieu d'utiliser un shared secret fixe on pourrait par
exemple utiliser un systeme type parametres de Diffie-Hellman.
Oui, mais dès que ton réseau est assez grand et que tes bornes sont disposées un peu partout à travers le monde, ca devient un peu lourd d'avoir un VLAN dédié distribué...
Oui.
IPsec rulez :-)
Heu.... ca c'est comme quand dans le draft ils nous sortent: | If encryption must be done at the AP, the AP must communicate with | Authentication Server (RADIUS Server) through IPSec.
Ben voyons ! Bien sur ! Et puis faut aussi mettre un reseau quantique entre l'AP et le serveur RADIUS ! Comme ca on ne peut pas sniffer le traffic !
J'ai pas vu un seul access point qui gerait l'IPsec... et je trouve que faire tourner Radius en IPsec est une rustine; il vaudrait mieux securiser Radius et basta. Au lieu d'utiliser un shared secret fixe on pourrait par exemple utiliser un systeme type parametres de Diffie-Hellman.
@+ Bertrand
Jacques Caron
On 02 Aug 2004 12:36:35 GMT, Bertrand wrote:
J'ai pas vu un seul access point qui gerait l'IPsec... et je trouve que faire tourner Radius en IPsec est une rustine; il vaudrait mieux securiser Radius et basta. Au lieu d'utiliser un shared secret fixe on pourrait par exemple utiliser un systeme type parametres de Diffie-Hellman.
Le successeur de RADIUS s'appelle diameter. Un truc sympa, qui a besoin d'une implémentation SCTP, de pas mal de crypto, qui utilise TLS le cas échéant, et de tout un tas de choses qui font que la probablitié de voir diameter implémenté dans des APs dans un proche avenir reste très faible.
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
On 02 Aug 2004 12:36:35 GMT, Bertrand <usenet@cykian.net> wrote:
J'ai pas vu un seul access point qui gerait l'IPsec... et je trouve que
faire tourner Radius en IPsec est une rustine; il vaudrait mieux
securiser Radius et basta. Au lieu d'utiliser un shared secret fixe
on pourrait par exemple utiliser un systeme type parametres de
Diffie-Hellman.
Le successeur de RADIUS s'appelle diameter. Un truc sympa, qui a besoin
d'une implémentation SCTP, de pas mal de crypto, qui utilise TLS le cas
échéant, et de tout un tas de choses qui font que la probablitié de voir
diameter implémenté dans des APs dans un proche avenir reste très faible.
Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/
J'ai pas vu un seul access point qui gerait l'IPsec... et je trouve que faire tourner Radius en IPsec est une rustine; il vaudrait mieux securiser Radius et basta. Au lieu d'utiliser un shared secret fixe on pourrait par exemple utiliser un systeme type parametres de Diffie-Hellman.
Le successeur de RADIUS s'appelle diameter. Un truc sympa, qui a besoin d'une implémentation SCTP, de pas mal de crypto, qui utilise TLS le cas échéant, et de tout un tas de choses qui font que la probablitié de voir diameter implémenté dans des APs dans un proche avenir reste très faible.
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
lbfred
IPsec rulez :-)
Heu.... ca c'est comme quand dans le draft ils nous sortent: | If encryption must be done at the AP, the AP must communicate with | Authentication Server (RADIUS Server) through IPSec.
Ben voyons ! Bien sur ! Et puis faut aussi mettre un reseau quantique entre l'AP et le serveur RADIUS ! Comme ca on ne peut pas sniffer le traffic !
J'ai pas vu un seul access point qui gerait l'IPsec...
sans aller jusque là, sonicwall propose des produits intégrant ipsec, cf : http://www.sonicwall.com/products/tz170_wireless.html
(ça fait AP, firewall, gateway ipsec, switch ethernet, mais pas le café ..., et non, je suis pas actionnaire, juste enduser)
faire tourner Radius en IPsec est une rustine; il vaudrait mieux securiser Radius et basta. Au lieu d'utiliser un shared secret fixe on pourrait par exemple utiliser un systeme type parametres de Diffie-Hellman.
bien sûr, mais pour le coup legacy rulez :-)
si tu as un Radius de plusieurs centaines ou milliers d'entrées, la migration (sur quoi d'ailleurs ... ) peut coûter beaucoup, beaucoup plus cher que la sécurisation de l'existant (accessoirement, des rustines comme IPSec, je les préfère à WPA au hasard si on parle du wifi)
Fred, 'hidden' cost-killer ;-)
IPsec rulez :-)
Heu.... ca c'est comme quand dans le draft ils nous sortent:
| If encryption must be done at the AP, the AP must communicate with
| Authentication Server (RADIUS Server) through IPSec.
Ben voyons ! Bien sur ! Et puis faut aussi mettre un reseau quantique
entre l'AP et le serveur RADIUS ! Comme ca on ne peut pas sniffer le
traffic !
J'ai pas vu un seul access point qui gerait l'IPsec...
sans aller jusque là, sonicwall propose des produits intégrant ipsec,
cf :
http://www.sonicwall.com/products/tz170_wireless.html
(ça fait AP, firewall, gateway ipsec, switch ethernet, mais pas le
café ..., et non, je suis pas actionnaire, juste enduser)
faire tourner Radius en IPsec est une rustine; il vaudrait mieux securiser
Radius et basta. Au lieu d'utiliser un shared secret fixe on pourrait par
exemple utiliser un systeme type parametres de Diffie-Hellman.
bien sûr, mais pour le coup legacy rulez :-)
si tu as un Radius de plusieurs centaines ou milliers d'entrées, la
migration (sur quoi d'ailleurs ... ) peut coûter beaucoup, beaucoup
plus cher que la sécurisation de l'existant (accessoirement, des
rustines comme IPSec, je les préfère à WPA au hasard si on parle du
wifi)
Heu.... ca c'est comme quand dans le draft ils nous sortent: | If encryption must be done at the AP, the AP must communicate with | Authentication Server (RADIUS Server) through IPSec.
Ben voyons ! Bien sur ! Et puis faut aussi mettre un reseau quantique entre l'AP et le serveur RADIUS ! Comme ca on ne peut pas sniffer le traffic !
J'ai pas vu un seul access point qui gerait l'IPsec...
sans aller jusque là, sonicwall propose des produits intégrant ipsec, cf : http://www.sonicwall.com/products/tz170_wireless.html
(ça fait AP, firewall, gateway ipsec, switch ethernet, mais pas le café ..., et non, je suis pas actionnaire, juste enduser)
faire tourner Radius en IPsec est une rustine; il vaudrait mieux securiser Radius et basta. Au lieu d'utiliser un shared secret fixe on pourrait par exemple utiliser un systeme type parametres de Diffie-Hellman.
bien sûr, mais pour le coup legacy rulez :-)
si tu as un Radius de plusieurs centaines ou milliers d'entrées, la migration (sur quoi d'ailleurs ... ) peut coûter beaucoup, beaucoup plus cher que la sécurisation de l'existant (accessoirement, des rustines comme IPSec, je les préfère à WPA au hasard si on parle du wifi)
Fred, 'hidden' cost-killer ;-)
T0t0
"Bertrand" wrote in message news:
Ben voyons ! Bien sur ! Et puis faut aussi mettre un reseau quantique entre l'AP et le serveur RADIUS ! Comme ca on ne peut pas sniffer le traffic !
Je ne parlais pas d'IPsec pour la partie Raduis, mais pour l'accès au réseau :-) D'autant plus que si la partie Radius est en filaire, il sera difficile de la voir depuis le hertzien. Dans ce cas, Radius me semble ok pour les échanges 802.1x.
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
"Bertrand" <usenet@cykian.net> wrote in message
news:pan.2004.08.02.12.41.10.313036@cykian.net
Ben voyons ! Bien sur ! Et puis faut aussi mettre un reseau quantique
entre l'AP et le serveur RADIUS ! Comme ca on ne peut pas sniffer le
traffic !
Je ne parlais pas d'IPsec pour la partie Raduis, mais pour l'accès au
réseau :-)
D'autant plus que si la partie Radius est en filaire, il sera
difficile de la voir depuis le hertzien. Dans ce cas, Radius me semble
ok pour les échanges 802.1x.
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
Ben voyons ! Bien sur ! Et puis faut aussi mettre un reseau quantique entre l'AP et le serveur RADIUS ! Comme ca on ne peut pas sniffer le traffic !
Je ne parlais pas d'IPsec pour la partie Raduis, mais pour l'accès au réseau :-) D'autant plus que si la partie Radius est en filaire, il sera difficile de la voir depuis le hertzien. Dans ce cas, Radius me semble ok pour les échanges 802.1x.
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
Cedric Blancher
Le Mon, 02 Aug 2004 00:10:19 +0000, Bertrand a écrit :
Alors qu'on propose le 802.1x comme alternative sure au WEP pour la protection des reseaux sans file type WiFi, il se trouve que ce standard est vulnerable a certaines attaques a cause d'une mauvaise implementation du protocole Radius dans la majorité des Access Points, etc (enfin, c'est ce que j'ai compris): http://home.jwu.edu/jwright/radius_vuln_00.txt
C'est surtout une description des conséquences d'une interception du trafic RADIUS lorsqu'on a cassé le secret partagé. Or il se trouve que sur pas mal d'implémentations, ce secret partagé est limité à une taille faible, alors qu'il doit être long et aléatoire pour éviter les attaques par dictionnaire et force brute.
Ensuite, une fois qu'on a le secret partagé, c'est du gâteau...
Pour mitiger cette attaque, qui est fort intéressante, il faut : 1. choisir un secret partagé RADIUS fort (>16 caractères) 2. segmenter son réseau pour éviter le sniff du trafic RADIUS
On pourra noter aussi que la plupart des bornes exportent leur trafic par un trunk 802.1q qui véhicule le trafic administratif d'une part (admin, RADIUS, etc.) sur un VLAN et le trafic du (ou des) réseau(x) WiFi proposé(s) sur un(des) VLAN(s) dédié(s). Si on peut sniffer ce trunk, on a non seulement le trafic RADIUS, mais aussi le trafic WiFi à destination du réseau filaire en clair :)
-- - Tu sais ce qui ferait bien sur le bar ? - Uh ? - TON NEZ ! *BUNK* -+- Culture générale in GPJ: Full Throttle -+-
Le Mon, 02 Aug 2004 00:10:19 +0000, Bertrand a écrit :
Alors qu'on propose le 802.1x comme alternative sure au WEP pour la
protection des reseaux sans file type WiFi, il se trouve que ce standard
est vulnerable a certaines attaques a cause d'une mauvaise implementation
du protocole Radius dans la majorité des Access Points, etc (enfin, c'est
ce que j'ai compris):
http://home.jwu.edu/jwright/radius_vuln_00.txt
C'est surtout une description des conséquences d'une interception du
trafic RADIUS lorsqu'on a cassé le secret partagé. Or il se trouve que
sur pas mal d'implémentations, ce secret partagé est limité à une
taille faible, alors qu'il doit être long et aléatoire pour éviter les
attaques par dictionnaire et force brute.
Ensuite, une fois qu'on a le secret partagé, c'est du gâteau...
Pour mitiger cette attaque, qui est fort intéressante, il faut :
1. choisir un secret partagé RADIUS fort (>16 caractères)
2. segmenter son réseau pour éviter le sniff du trafic RADIUS
On pourra noter aussi que la plupart des bornes exportent leur trafic par
un trunk 802.1q qui véhicule le trafic administratif d'une part (admin,
RADIUS, etc.) sur un VLAN et le trafic du (ou des) réseau(x) WiFi
proposé(s) sur un(des) VLAN(s) dédié(s). Si on peut sniffer ce trunk, on
a non seulement le trafic RADIUS, mais aussi le trafic WiFi à destination
du réseau filaire en clair :)
--
- Tu sais ce qui ferait bien sur le bar ?
- Uh ?
- TON NEZ ! *BUNK*
-+- Culture générale in GPJ: Full Throttle -+-
Le Mon, 02 Aug 2004 00:10:19 +0000, Bertrand a écrit :
Alors qu'on propose le 802.1x comme alternative sure au WEP pour la protection des reseaux sans file type WiFi, il se trouve que ce standard est vulnerable a certaines attaques a cause d'une mauvaise implementation du protocole Radius dans la majorité des Access Points, etc (enfin, c'est ce que j'ai compris): http://home.jwu.edu/jwright/radius_vuln_00.txt
C'est surtout une description des conséquences d'une interception du trafic RADIUS lorsqu'on a cassé le secret partagé. Or il se trouve que sur pas mal d'implémentations, ce secret partagé est limité à une taille faible, alors qu'il doit être long et aléatoire pour éviter les attaques par dictionnaire et force brute.
Ensuite, une fois qu'on a le secret partagé, c'est du gâteau...
Pour mitiger cette attaque, qui est fort intéressante, il faut : 1. choisir un secret partagé RADIUS fort (>16 caractères) 2. segmenter son réseau pour éviter le sniff du trafic RADIUS
On pourra noter aussi que la plupart des bornes exportent leur trafic par un trunk 802.1q qui véhicule le trafic administratif d'une part (admin, RADIUS, etc.) sur un VLAN et le trafic du (ou des) réseau(x) WiFi proposé(s) sur un(des) VLAN(s) dédié(s). Si on peut sniffer ce trunk, on a non seulement le trafic RADIUS, mais aussi le trafic WiFi à destination du réseau filaire en clair :)
-- - Tu sais ce qui ferait bien sur le bar ? - Uh ? - TON NEZ ! *BUNK* -+- Culture générale in GPJ: Full Throttle -+-
