j'envisage de mettre en place une solution wifi en utilisant le
protocole pppoe.
c'est a dire que sur les machines clientes se trouvent un client pppoe
qui contacte via une carte wifi et un AP le serveur pppoe.
le serveur pppoe tourne sur linux, les clients seront de tous types:
mac, win, linux, bsd, du moment qu'ils ont un client pppoe
l'authentification se fera par user/pass CHAP
donc si je ne dis pas de betise, l'un des risques dans cette
architecture est de se faire sniffer les trames ethernet entre le
client et le serveur.
Est-ce le seul risque ? Est-ce une architecture raisonnable (usage
semi-professionnel sans données rellement confidentielles) ? est-il
aisé de sniffer les trames ethernet ?
Je comprend tout à fait qu'il serait préferable de faire transiter un
flux TCP/IP crypté (VPN) mais je n'ai pas (encore) les compétences
pour le mettre en place. Donc en attendant j'étudie les solutions
alternatives dont le pppoe.
John nous disait récement dans fr.comp.securite <news: :
est-il aisé de sniffer les trames ethernet ?
Dans une solution wifi, oui. Ce n'est pas comme dans une liaison par cable, où les trames sont dirigées d'un point A à un point B sans pouvoir dévier du trajet imposé, à savoir le cable lui-même, et où il faut donc se brancher sur le cable pour écouter ce qui passe. Ici les trames se baladent à l'air libre en échappant à tous controle. Un scanner "radio" réglé sur la bonne longueur d'onde posé à côté de ta fenêtre, et hop les trames sont "capturées". Cependant, la question lorsqu'il s'agit de wifi n'est pas de savoir s'il est possible de sniffer les trames (car ça le sera toujours), mais s'il est possible d'en faire quelque chose.
Je comprend tout à fait qu'il serait préferable de faire transiter un flux TCP/IP crypté (VPN) mais je n'ai pas (encore) les compétences pour le mettre en place.
Il me semble que la plus part des solutions wifi actuelles dispose d'un système de cryptage entre les différents éléments, mais je ne sais pas ce que ça vaut.
Donc en attendant j'étudie les solutions alternatives dont le pppoe.
Sauf erreur (possible) de ma part, PPPoE est un simple protocole de transfert permettant de faire passer de l'IP dans une partie de réseau qui n'est pas IP. Il n'apporte donc strictement rien de plus en matière de sécurité.
Merci pour vos avis eclairés sur le sujet.
De rien, mais mon avis n'est éclairé que par une bougie, attend quand même la réponse de vrais spécialistes.
-- "Si ceux qui disent du mal de moi savaient exactement ce que je pense d'eux , ils en diraient bien davantage." Sacha Guitry
John nous disait récement dans fr.comp.securite
<news:f4b246ab.0309111218.3f96d43a@posting.google.com> :
est-il aisé de sniffer les trames ethernet ?
Dans une solution wifi, oui. Ce n'est pas comme dans une liaison par
cable, où les trames sont dirigées d'un point A à un point B sans
pouvoir dévier du trajet imposé, à savoir le cable lui-même, et où il
faut donc se brancher sur le cable pour écouter ce qui passe.
Ici les trames se baladent à l'air libre en échappant à tous controle.
Un scanner "radio" réglé sur la bonne longueur d'onde posé à côté de ta
fenêtre, et hop les trames sont "capturées". Cependant, la question
lorsqu'il s'agit de wifi n'est pas de savoir s'il est possible de
sniffer les trames (car ça le sera toujours), mais s'il est possible
d'en faire quelque chose.
Je comprend tout à fait qu'il serait préferable de faire transiter
un flux TCP/IP crypté (VPN) mais je n'ai pas (encore) les
compétences pour le mettre en place.
Il me semble que la plus part des solutions wifi actuelles dispose
d'un système de cryptage entre les différents éléments, mais je ne sais
pas ce que ça vaut.
Donc en attendant j'étudie les solutions alternatives dont le pppoe.
Sauf erreur (possible) de ma part, PPPoE est un simple protocole de
transfert permettant de faire passer de l'IP dans une partie de réseau
qui n'est pas IP. Il n'apporte donc strictement rien de plus en matière
de sécurité.
Merci pour vos avis eclairés sur le sujet.
De rien, mais mon avis n'est éclairé que par une bougie, attend quand
même la réponse de vrais spécialistes.
--
"Si ceux qui disent du mal de moi savaient exactement ce que je
pense d'eux , ils en diraient bien davantage."
Sacha Guitry
John nous disait récement dans fr.comp.securite <news: :
est-il aisé de sniffer les trames ethernet ?
Dans une solution wifi, oui. Ce n'est pas comme dans une liaison par cable, où les trames sont dirigées d'un point A à un point B sans pouvoir dévier du trajet imposé, à savoir le cable lui-même, et où il faut donc se brancher sur le cable pour écouter ce qui passe. Ici les trames se baladent à l'air libre en échappant à tous controle. Un scanner "radio" réglé sur la bonne longueur d'onde posé à côté de ta fenêtre, et hop les trames sont "capturées". Cependant, la question lorsqu'il s'agit de wifi n'est pas de savoir s'il est possible de sniffer les trames (car ça le sera toujours), mais s'il est possible d'en faire quelque chose.
Je comprend tout à fait qu'il serait préferable de faire transiter un flux TCP/IP crypté (VPN) mais je n'ai pas (encore) les compétences pour le mettre en place.
Il me semble que la plus part des solutions wifi actuelles dispose d'un système de cryptage entre les différents éléments, mais je ne sais pas ce que ça vaut.
Donc en attendant j'étudie les solutions alternatives dont le pppoe.
Sauf erreur (possible) de ma part, PPPoE est un simple protocole de transfert permettant de faire passer de l'IP dans une partie de réseau qui n'est pas IP. Il n'apporte donc strictement rien de plus en matière de sécurité.
Merci pour vos avis eclairés sur le sujet.
De rien, mais mon avis n'est éclairé que par une bougie, attend quand même la réponse de vrais spécialistes.
-- "Si ceux qui disent du mal de moi savaient exactement ce que je pense d'eux , ils en diraient bien davantage." Sacha Guitry
Cedric Blancher
Dans sa prose, John nous ecrivait :
j'envisage de mettre en place une solution wifi en utilisant le protocole pppoe. c'est a dire que sur les machines clientes se trouvent un client pppoe qui contacte via une carte wifi et un AP le serveur pppoe. le serveur pppoe tourne sur linux, les clients seront de tous types: mac, win, linux, bsd, du moment qu'ils ont un client pppoe l'authentification se fera par user/pass CHAP
C'est quoi l'intérêt de PPPoE par rapport à EAP ? D'autant qu'un système d'authentification PPPoE est vulnérable au MiM, c'est à dire que si le client s'authentifie bien serveur, le serveur, lui, par contre, n'est pas authentifié par le client, ce qui pose un problème. En effet, un utilisateur malin, pourra très simplement utiliser un système de relai pour s'authentifier, consistant à renvoyer le challenge reçu à une station légitime, récupérer la réponse et la renvoyer au serveur. C'est ce genre d'attaque qui a définitivement disqualifié les authentification reposant sur des challenges MD5 en wireless (EAP-MD5 et Cisco LEAP par exemple).
D'autant plus que l'authentification PPPoE se fera nécessairement après l'association du client, ce qui laisse l'accès libre à n'importe qui à la borne, et donc une aisance supplémentaire pour travailler.
Bref, je m'orienterait plutôt vers une solution type 802.1x que supporte aujourd'hui pas mal de points d'accès, avec une authentification PEAP par exemple qui permet une authentification mutuelle des deux parties (forte pour le serveur d'authentification). Il faut certes un serveur RADIUS sous la main, mais on en trouve des très bien dans le monde du logiciel libre, de mise en oeuvre aisée.
En outre, l'avantage de 802.1x est qu'il permet de générer des clés WEP différentes à chaque authentification et de les renouveler régulièrement, nuançant par là _la_ grosse faille de WEP.
-- BOFH excuse #129:
The ring needs another token
Dans sa prose, John nous ecrivait :
j'envisage de mettre en place une solution wifi en utilisant le protocole
pppoe.
c'est a dire que sur les machines clientes se trouvent un client pppoe qui
contacte via une carte wifi et un AP le serveur pppoe. le serveur pppoe
tourne sur linux, les clients seront de tous types: mac, win, linux, bsd,
du moment qu'ils ont un client pppoe l'authentification se fera par
user/pass CHAP
C'est quoi l'intérêt de PPPoE par rapport à EAP ? D'autant qu'un
système d'authentification PPPoE est vulnérable au MiM, c'est à dire
que si le client s'authentifie bien serveur, le serveur, lui, par contre,
n'est pas authentifié par le client, ce qui pose un problème. En effet,
un utilisateur malin, pourra très simplement utiliser un système de
relai pour s'authentifier, consistant à renvoyer le challenge reçu à
une station légitime, récupérer la réponse et la renvoyer au serveur.
C'est ce genre d'attaque qui a définitivement disqualifié les
authentification reposant sur des challenges MD5 en wireless (EAP-MD5 et
Cisco LEAP par exemple).
D'autant plus que l'authentification PPPoE se fera nécessairement après
l'association du client, ce qui laisse l'accès libre à n'importe qui à
la borne, et donc une aisance supplémentaire pour travailler.
Bref, je m'orienterait plutôt vers une solution type 802.1x que supporte
aujourd'hui pas mal de points d'accès, avec une authentification PEAP par
exemple qui permet une authentification mutuelle des deux parties (forte
pour le serveur d'authentification). Il faut certes un serveur RADIUS sous
la main, mais on en trouve des très bien dans le monde du logiciel libre,
de mise en oeuvre aisée.
En outre, l'avantage de 802.1x est qu'il permet de générer des clés WEP
différentes à chaque authentification et de les renouveler
régulièrement, nuançant par là _la_ grosse faille de WEP.
j'envisage de mettre en place une solution wifi en utilisant le protocole pppoe. c'est a dire que sur les machines clientes se trouvent un client pppoe qui contacte via une carte wifi et un AP le serveur pppoe. le serveur pppoe tourne sur linux, les clients seront de tous types: mac, win, linux, bsd, du moment qu'ils ont un client pppoe l'authentification se fera par user/pass CHAP
C'est quoi l'intérêt de PPPoE par rapport à EAP ? D'autant qu'un système d'authentification PPPoE est vulnérable au MiM, c'est à dire que si le client s'authentifie bien serveur, le serveur, lui, par contre, n'est pas authentifié par le client, ce qui pose un problème. En effet, un utilisateur malin, pourra très simplement utiliser un système de relai pour s'authentifier, consistant à renvoyer le challenge reçu à une station légitime, récupérer la réponse et la renvoyer au serveur. C'est ce genre d'attaque qui a définitivement disqualifié les authentification reposant sur des challenges MD5 en wireless (EAP-MD5 et Cisco LEAP par exemple).
D'autant plus que l'authentification PPPoE se fera nécessairement après l'association du client, ce qui laisse l'accès libre à n'importe qui à la borne, et donc une aisance supplémentaire pour travailler.
Bref, je m'orienterait plutôt vers une solution type 802.1x que supporte aujourd'hui pas mal de points d'accès, avec une authentification PEAP par exemple qui permet une authentification mutuelle des deux parties (forte pour le serveur d'authentification). Il faut certes un serveur RADIUS sous la main, mais on en trouve des très bien dans le monde du logiciel libre, de mise en oeuvre aisée.
En outre, l'avantage de 802.1x est qu'il permet de générer des clés WEP différentes à chaque authentification et de les renouveler régulièrement, nuançant par là _la_ grosse faille de WEP.
-- BOFH excuse #129:
The ring needs another token
Eric Razny
"Stephane Catteau" a écrit dans le message de news:
John nous disait récement dans fr.comp.securite <news: :
Je comprend tout à fait qu'il serait préferable de faire transiter un flux TCP/IP crypté (VPN) mais je n'ai pas (encore) les compétences pour le mettre en place.
Il me semble que la plus part des solutions wifi actuelles dispose d'un système de cryptage entre les différents éléments, mais je ne sais pas ce que ça vaut.
Le wep est effectivement troué et les outils dispos.
Merci pour vos avis eclairés sur le sujet.
De rien, mais mon avis n'est éclairé que par une bougie, attend quand même la réponse de vrais spécialistes.
Je ne suis même pas un novice en wifi (et comme un client va s'équiper dans quelques mois je vais être obligé de m'y mettre), mais un misc précédent (le 6) faisait état, plus que d'un risque de sniffing -un vrai cryptage peut être mis en place-, des possibilité de DOS particulièrement coton à éviter, si c'est seulement possible.
Eric.
"Stephane Catteau" <stephane@sc4x.net> a écrit dans le message de
news:bjr1l4.3vvf6bn.1@sc4x.org...
John nous disait récement dans fr.comp.securite
<news:f4b246ab.0309111218.3f96d43a@posting.google.com> :
Je comprend tout à fait qu'il serait préferable de faire transiter
un flux TCP/IP crypté (VPN) mais je n'ai pas (encore) les
compétences pour le mettre en place.
Il me semble que la plus part des solutions wifi actuelles dispose
d'un système de cryptage entre les différents éléments, mais je ne sais
pas ce que ça vaut.
Le wep est effectivement troué et les outils dispos.
Merci pour vos avis eclairés sur le sujet.
De rien, mais mon avis n'est éclairé que par une bougie, attend quand
même la réponse de vrais spécialistes.
Je ne suis même pas un novice en wifi (et comme un client va s'équiper dans
quelques mois je vais être obligé de m'y mettre), mais un misc précédent (le
6) faisait état, plus que d'un risque de sniffing -un vrai cryptage peut
être mis en place-, des possibilité de DOS particulièrement coton à éviter,
si c'est seulement possible.
"Stephane Catteau" a écrit dans le message de news:
John nous disait récement dans fr.comp.securite <news: :
Je comprend tout à fait qu'il serait préferable de faire transiter un flux TCP/IP crypté (VPN) mais je n'ai pas (encore) les compétences pour le mettre en place.
Il me semble que la plus part des solutions wifi actuelles dispose d'un système de cryptage entre les différents éléments, mais je ne sais pas ce que ça vaut.
Le wep est effectivement troué et les outils dispos.
Merci pour vos avis eclairés sur le sujet.
De rien, mais mon avis n'est éclairé que par une bougie, attend quand même la réponse de vrais spécialistes.
Je ne suis même pas un novice en wifi (et comme un client va s'équiper dans quelques mois je vais être obligé de m'y mettre), mais un misc précédent (le 6) faisait état, plus que d'un risque de sniffing -un vrai cryptage peut être mis en place-, des possibilité de DOS particulièrement coton à éviter, si c'est seulement possible.
Eric.
Stephane Sales
Stephane Catteau wrote:
Je comprend tout à fait qu'il serait préferable de faire transiter un flux TCP/IP crypté (VPN) mais je n'ai pas (encore) les compétences pour le mettre en place.
Il me semble que la plus part des solutions wifi actuelles dispose d'un système de cryptage entre les différents éléments, mais je ne sais pas ce que ça vaut.
d'après le misc 6 et son dossier sur le wireless, pas grand chose.D'ailleurs au moins l'un des auteurs de ce dossier est parmi nous si je ne m'abuse ;) -- Agissez contre les brevets européens : http://www.april.org/actions/brevets/academie.html
Stephane Catteau wrote:
Je comprend tout à fait qu'il serait préferable de faire transiter
un flux TCP/IP crypté (VPN) mais je n'ai pas (encore) les
compétences pour le mettre en place.
Il me semble que la plus part des solutions wifi actuelles dispose
d'un système de cryptage entre les différents éléments, mais je ne sais
pas ce que ça vaut.
d'après le misc 6 et son dossier sur le wireless, pas grand chose.D'ailleurs
au moins l'un des auteurs de ce dossier est parmi nous si je ne m'abuse ;)
--
Agissez contre les brevets européens :
http://www.april.org/actions/brevets/academie.html
Je comprend tout à fait qu'il serait préferable de faire transiter un flux TCP/IP crypté (VPN) mais je n'ai pas (encore) les compétences pour le mettre en place.
Il me semble que la plus part des solutions wifi actuelles dispose d'un système de cryptage entre les différents éléments, mais je ne sais pas ce que ça vaut.
d'après le misc 6 et son dossier sur le wireless, pas grand chose.D'ailleurs au moins l'un des auteurs de ce dossier est parmi nous si je ne m'abuse ;) -- Agissez contre les brevets européens : http://www.april.org/actions/brevets/academie.html
Cedric Blancher
Dans sa prose, Stephane Sales nous ecrivait :
d'après le misc 6 et son dossier sur le wireless, pas grand chose.D'ailleurs au moins l'un des auteurs de ce dossier est parmi nous si je ne m'abuse ;)
Les choses ont pas mal évolué depuis, avec l'introduction de WPA d'une part, mais surtout avec une intégration de 802.1x plus poussée, qui permet de dériver des clés aléatoires des éléments d'authentification. Donc, même si on reste en WEP, le simple fait que chaque client WiFi utilise un clé unique qui pourra éventuellement être renégociée rend les attaques contre le WEP nettement plus difficile, puisqu'elles supposent la collecte d'une nombre de trames chiffrées avec la même clé important. De plus, comme les clés sont uniques, les clients valides ne peuvent plus se sniffer entre eux. Enfin on peut passer en chiffrement WPA si on a un driver qui le supporte en attendant le draft 802.11i final.
En outre, côté EAP (protocole d'authentification sur 802.1x), on dispose maintenant de solutions nettement plus robustes que EAP-MD5 ou LEAP, comme PEAP (Protected-EAP), EAP-TLS, EAP-TTLS qui mettent en oeuvre des authentifications mutuelles, à base de certificat pour le serveur et de mot de passe ou certificat pour le client, ce qui permet d'éviter des attaques de type MiM.
Enfin, on peut évidemment coller une couche supplémentaire de sécurité par dessus le tout (IPSEC, SSL, SSH, etc.), ça ne gâte rien.
Un exemple de choses assez poussées qu'on arrive à mettre en place maintenant est un AP avec authentification qui donne accès à un VLAN particulier en fonction du résultat de l'authentification, et éventuellement un dernier VLAN poubelle pour les clients non authentifiés. On a aussi des AP capables de gérer plusieurs SSID différents, avec des configurations de sécurité différentes (authentification, chiffrement, etc.) donnant chacun accès à un ou plusieurs VLAN distincts.
Reste le gros problème des DoS basés sur les trames de management, qui ne sont ni chiffrées, ni authentifiées de manière sûre.
Bref, on arrive à faire des choses sympas en terme de sécurité maintenant. Ce n'est pas le Pérou, mais ça commence à tenir la route.
-- BOFH excuse #154:
You can tune a file system, but you can't tune a fish (from most tunefs man pages)
Dans sa prose, Stephane Sales nous ecrivait :
d'après le misc 6 et son dossier sur le wireless, pas grand
chose.D'ailleurs au moins l'un des auteurs de ce dossier est parmi nous si
je ne m'abuse ;)
Les choses ont pas mal évolué depuis, avec l'introduction de WPA d'une
part, mais surtout avec une intégration de 802.1x plus poussée, qui
permet de dériver des clés aléatoires des éléments
d'authentification. Donc, même si on reste en WEP, le simple fait que
chaque client WiFi utilise un clé unique qui pourra éventuellement être
renégociée rend les attaques contre le WEP nettement plus difficile,
puisqu'elles supposent la collecte d'une nombre de trames chiffrées avec
la même clé important. De plus, comme les clés sont uniques, les
clients valides ne peuvent plus se sniffer entre eux. Enfin on peut passer
en chiffrement WPA si on a un driver qui le supporte en attendant le draft
802.11i final.
En outre, côté EAP (protocole d'authentification sur 802.1x), on dispose
maintenant de solutions nettement plus robustes que EAP-MD5 ou LEAP, comme
PEAP (Protected-EAP), EAP-TLS, EAP-TTLS qui mettent en oeuvre des
authentifications mutuelles, à base de certificat pour le serveur et de
mot de passe ou certificat pour le client, ce qui permet d'éviter des
attaques de type MiM.
Enfin, on peut évidemment coller une couche supplémentaire de sécurité
par dessus le tout (IPSEC, SSL, SSH, etc.), ça ne gâte rien.
Un exemple de choses assez poussées qu'on arrive à mettre en place
maintenant est un AP avec authentification qui donne accès à un VLAN
particulier en fonction du résultat de l'authentification, et
éventuellement un dernier VLAN poubelle pour les clients non
authentifiés. On a aussi des AP capables de gérer plusieurs SSID
différents, avec des configurations de sécurité différentes
(authentification, chiffrement, etc.) donnant chacun accès à un ou
plusieurs VLAN distincts.
Reste le gros problème des DoS basés sur les trames de management, qui
ne sont ni chiffrées, ni authentifiées de manière sûre.
Bref, on arrive à faire des choses sympas en terme de sécurité
maintenant. Ce n'est pas le Pérou, mais ça commence à tenir la route.
--
BOFH excuse #154:
You can tune a file system, but you can't tune a fish (from most tunefs
man pages)
d'après le misc 6 et son dossier sur le wireless, pas grand chose.D'ailleurs au moins l'un des auteurs de ce dossier est parmi nous si je ne m'abuse ;)
Les choses ont pas mal évolué depuis, avec l'introduction de WPA d'une part, mais surtout avec une intégration de 802.1x plus poussée, qui permet de dériver des clés aléatoires des éléments d'authentification. Donc, même si on reste en WEP, le simple fait que chaque client WiFi utilise un clé unique qui pourra éventuellement être renégociée rend les attaques contre le WEP nettement plus difficile, puisqu'elles supposent la collecte d'une nombre de trames chiffrées avec la même clé important. De plus, comme les clés sont uniques, les clients valides ne peuvent plus se sniffer entre eux. Enfin on peut passer en chiffrement WPA si on a un driver qui le supporte en attendant le draft 802.11i final.
En outre, côté EAP (protocole d'authentification sur 802.1x), on dispose maintenant de solutions nettement plus robustes que EAP-MD5 ou LEAP, comme PEAP (Protected-EAP), EAP-TLS, EAP-TTLS qui mettent en oeuvre des authentifications mutuelles, à base de certificat pour le serveur et de mot de passe ou certificat pour le client, ce qui permet d'éviter des attaques de type MiM.
Enfin, on peut évidemment coller une couche supplémentaire de sécurité par dessus le tout (IPSEC, SSL, SSH, etc.), ça ne gâte rien.
Un exemple de choses assez poussées qu'on arrive à mettre en place maintenant est un AP avec authentification qui donne accès à un VLAN particulier en fonction du résultat de l'authentification, et éventuellement un dernier VLAN poubelle pour les clients non authentifiés. On a aussi des AP capables de gérer plusieurs SSID différents, avec des configurations de sécurité différentes (authentification, chiffrement, etc.) donnant chacun accès à un ou plusieurs VLAN distincts.
Reste le gros problème des DoS basés sur les trames de management, qui ne sont ni chiffrées, ni authentifiées de manière sûre.
Bref, on arrive à faire des choses sympas en terme de sécurité maintenant. Ce n'est pas le Pérou, mais ça commence à tenir la route.
-- BOFH excuse #154:
You can tune a file system, but you can't tune a fish (from most tunefs man pages)
Eric Masson
"Cedric" == Cedric Blancher writes:
Cedric> Bref, on arrive à faire des choses sympas en terme de sécurité Cedric> maintenant. Ce n'est pas le Pérou, mais ça commence à tenir la Cedric> route.
Un update dans un prochain Misc peut-être ?
Eric Masson
-- NC> Ben quoi ? C'est déshonorant le GCU ? (Si oui, là, je prendrais des risques inconsidérés...) Pas ce que j'ai dit Mais passer du GCU au GNU.... -+- HP in: <http://www.le-gnu.net> - Grandeur et décadence -+-
Cedric> Bref, on arrive à faire des choses sympas en terme de sécurité
Cedric> maintenant. Ce n'est pas le Pérou, mais ça commence à tenir la
Cedric> route.
Un update dans un prochain Misc peut-être ?
Eric Masson
--
NC> Ben quoi ? C'est déshonorant le GCU ? (Si oui, là, je prendrais
des risques inconsidérés...)
Pas ce que j'ai dit Mais passer du GCU au GNU....
-+- HP in: <http://www.le-gnu.net> - Grandeur et décadence -+-
Cedric> Bref, on arrive à faire des choses sympas en terme de sécurité Cedric> maintenant. Ce n'est pas le Pérou, mais ça commence à tenir la Cedric> route.
Un update dans un prochain Misc peut-être ?
Eric Masson
-- NC> Ben quoi ? C'est déshonorant le GCU ? (Si oui, là, je prendrais des risques inconsidérés...) Pas ce que j'ai dit Mais passer du GCU au GNU.... -+- HP in: <http://www.le-gnu.net> - Grandeur et décadence -+-
Annie D.
Stephane Catteau wrote:
Sauf erreur (possible) de ma part, PPPoE est un simple protocole de transfert permettant de faire passer de l'IP dans une partie de réseau qui n'est pas IP.
PPPoE n'a rien à voir avec IP. Il sert à faire passer du PPP sur un réseau ethernet, qui n'est pas point à point. En ce sens, il n'est pas plus sécurisé que PPP et ses NCP.
Stephane Catteau wrote:
Sauf erreur (possible) de ma part, PPPoE est un simple protocole de
transfert permettant de faire passer de l'IP dans une partie de réseau
qui n'est pas IP.
PPPoE n'a rien à voir avec IP. Il sert à faire passer du PPP sur un
réseau ethernet, qui n'est pas point à point. En ce sens, il n'est pas
plus sécurisé que PPP et ses NCP.
Sauf erreur (possible) de ma part, PPPoE est un simple protocole de transfert permettant de faire passer de l'IP dans une partie de réseau qui n'est pas IP.
PPPoE n'a rien à voir avec IP. Il sert à faire passer du PPP sur un réseau ethernet, qui n'est pas point à point. En ce sens, il n'est pas plus sécurisé que PPP et ses NCP.
T0t0
"Cedric Blancher" wrote in message news:
Les choses ont pas mal évolué depuis, avec l'introduction de WPA d'une part, mais surtout avec une intégration de 802.1x plus poussée, qui permet de dériver des clés aléatoires des éléments d'authentification. Donc, même si on reste en WEP, le simple fait que chaque client WiFi utilise un clé unique qui pourra éventuellement être renégociée rend les attaques contre le WEP nettement plus difficile, puisqu'elles supposent la collecte d'une nombre de trames chiffrées avec la même clé important. De plus, comme les clés sont uniques, les clients valides ne peuvent plus se sniffer entre eux. Enfin on peut passer en chiffrement WPA si on a un driver qui le supporte en attendant le draft 802.11i final.
J'avais lu une attaque qui me semblait assez puissante contre le wep, et qui ne nécessite à priori pas trop de trames. Je suis pas sûr d'avoir bien compris :-(
Il s'agit en fait d'identifier une partie de la trame qui correspond à l'adresse IP destination (le chiffrement n'étant qu'à base de XOR, l'emplacement des informations ne devrait pas être modifié) Il faut aussi que sur le réseau wifi, on ait quasiment toujours la même machine en destination, ce qui est souvent le cas lors d'une sortie par une passerelle par défaut. On peut alors modifier la trame chiffrée par wep pour introduire une adresse destination de son choix. La linéarité du CRC nous permet de faire cela tout en gardant un CRC valide.
On peut ainsi envoyer une trame chiffrée et récupérer le clair (en mettant notre machine en destination) La clé est ensuite obtenue en faisant un XOR des deux.
N'étant pas du tout (mais alors pas du tout) un spécialiste de crypto, je me demandais si j'avais bien compris le principe, et s'il existait des outils qui proposent une attaque de ce genre ?
La rapidité de cette attaque rendrait la dérivation de clefs moins efficace, voir pas du tout...
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
"Cedric Blancher" <blancher@cartel-securite.fr> wrote in message
news:pan.2003.09.12.09.25.39.297254@cartel-securite.fr
Les choses ont pas mal évolué depuis, avec l'introduction de WPA d'une
part, mais surtout avec une intégration de 802.1x plus poussée, qui
permet de dériver des clés aléatoires des éléments
d'authentification. Donc, même si on reste en WEP, le simple fait que
chaque client WiFi utilise un clé unique qui pourra éventuellement être
renégociée rend les attaques contre le WEP nettement plus difficile,
puisqu'elles supposent la collecte d'une nombre de trames chiffrées avec
la même clé important. De plus, comme les clés sont uniques, les
clients valides ne peuvent plus se sniffer entre eux. Enfin on peut passer
en chiffrement WPA si on a un driver qui le supporte en attendant le draft
802.11i final.
J'avais lu une attaque qui me semblait assez puissante contre le wep,
et qui ne nécessite à priori pas trop de trames.
Je suis pas sûr d'avoir bien compris :-(
Il s'agit en fait d'identifier une partie de la trame qui correspond
à l'adresse IP destination (le chiffrement n'étant qu'à base de XOR,
l'emplacement des informations ne devrait pas être modifié)
Il faut aussi que sur le réseau wifi, on ait quasiment toujours la
même machine en destination, ce qui est souvent le cas lors d'une
sortie par une passerelle par défaut.
On peut alors modifier la trame chiffrée par wep pour introduire une
adresse destination de son choix. La linéarité du CRC nous permet de
faire cela tout en gardant un CRC valide.
On peut ainsi envoyer une trame chiffrée et récupérer le clair (en
mettant notre machine en destination)
La clé est ensuite obtenue en faisant un XOR des deux.
N'étant pas du tout (mais alors pas du tout) un spécialiste de crypto,
je me demandais si j'avais bien compris le principe, et s'il existait
des outils qui proposent une attaque de ce genre ?
La rapidité de cette attaque rendrait la dérivation de clefs moins
efficace, voir pas du tout...
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
Les choses ont pas mal évolué depuis, avec l'introduction de WPA d'une part, mais surtout avec une intégration de 802.1x plus poussée, qui permet de dériver des clés aléatoires des éléments d'authentification. Donc, même si on reste en WEP, le simple fait que chaque client WiFi utilise un clé unique qui pourra éventuellement être renégociée rend les attaques contre le WEP nettement plus difficile, puisqu'elles supposent la collecte d'une nombre de trames chiffrées avec la même clé important. De plus, comme les clés sont uniques, les clients valides ne peuvent plus se sniffer entre eux. Enfin on peut passer en chiffrement WPA si on a un driver qui le supporte en attendant le draft 802.11i final.
J'avais lu une attaque qui me semblait assez puissante contre le wep, et qui ne nécessite à priori pas trop de trames. Je suis pas sûr d'avoir bien compris :-(
Il s'agit en fait d'identifier une partie de la trame qui correspond à l'adresse IP destination (le chiffrement n'étant qu'à base de XOR, l'emplacement des informations ne devrait pas être modifié) Il faut aussi que sur le réseau wifi, on ait quasiment toujours la même machine en destination, ce qui est souvent le cas lors d'une sortie par une passerelle par défaut. On peut alors modifier la trame chiffrée par wep pour introduire une adresse destination de son choix. La linéarité du CRC nous permet de faire cela tout en gardant un CRC valide.
On peut ainsi envoyer une trame chiffrée et récupérer le clair (en mettant notre machine en destination) La clé est ensuite obtenue en faisant un XOR des deux.
N'étant pas du tout (mais alors pas du tout) un spécialiste de crypto, je me demandais si j'avais bien compris le principe, et s'il existait des outils qui proposent une attaque de ce genre ?
La rapidité de cette attaque rendrait la dérivation de clefs moins efficace, voir pas du tout...
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
Cedric Blancher
Dans sa prose, T0t0 nous ecrivait :
Il s'agit en fait d'identifier une partie de la trame qui correspond à l'adresse IP destination (le chiffrement n'étant qu'à base de XOR, l'emplacement des informations ne devrait pas être modifié)
Pour autant que je sache, le chiffrement, c'est du RC4. C'est le calcul de la somme d'intégrité qui est à base de XOR.
On peut ainsi envoyer une trame chiffrée et récupérer le clair (en mettant notre machine en destination) La clé est ensuite obtenue en faisant un XOR des deux.
Oui, mais là, il faut une machine sur le réseau filaire, c'est quand même vachement contraignant, non ?
La rapidité de cette attaque rendrait la dérivation de clefs moins efficace, voir pas du tout...
Faut voir le nombre de trames nécessaires.
-- Quelqu'un connait il la vitesse en mètres par seconde du chameau d'Egypte ? -+- JM in: Guide du Cabaliste Usenet - Bien configurer son chameau -+-
Dans sa prose, T0t0 nous ecrivait :
Il s'agit en fait d'identifier une partie de la trame qui correspond à
l'adresse IP destination (le chiffrement n'étant qu'à base de XOR,
l'emplacement des informations ne devrait pas être modifié)
Pour autant que je sache, le chiffrement, c'est du RC4. C'est le calcul de
la somme d'intégrité qui est à base de XOR.
On peut ainsi envoyer une trame chiffrée et récupérer le clair (en
mettant notre machine en destination) La clé est ensuite obtenue en
faisant un XOR des deux.
Oui, mais là, il faut une machine sur le réseau filaire, c'est quand
même vachement contraignant, non ?
La rapidité de cette attaque rendrait la dérivation de clefs moins
efficace, voir pas du tout...
Faut voir le nombre de trames nécessaires.
--
Quelqu'un connait il la vitesse en mètres par seconde du
chameau d'Egypte ?
-+- JM in: Guide du Cabaliste Usenet - Bien configurer son chameau -+-
Il s'agit en fait d'identifier une partie de la trame qui correspond à l'adresse IP destination (le chiffrement n'étant qu'à base de XOR, l'emplacement des informations ne devrait pas être modifié)
Pour autant que je sache, le chiffrement, c'est du RC4. C'est le calcul de la somme d'intégrité qui est à base de XOR.
On peut ainsi envoyer une trame chiffrée et récupérer le clair (en mettant notre machine en destination) La clé est ensuite obtenue en faisant un XOR des deux.
Oui, mais là, il faut une machine sur le réseau filaire, c'est quand même vachement contraignant, non ?
La rapidité de cette attaque rendrait la dérivation de clefs moins efficace, voir pas du tout...
Faut voir le nombre de trames nécessaires.
-- Quelqu'un connait il la vitesse en mètres par seconde du chameau d'Egypte ? -+- JM in: Guide du Cabaliste Usenet - Bien configurer son chameau -+-
Pierre LALET
Oui, mais là, il faut une machine sur le réseau filaire, c'est quand même vachement contraignant, non ?
Je vais peut-être (surement même, vu que tu sembles sur de toi, mais j'ai même pas peur) dire une bêtise, mais tu peux te contenter d'avoir une machine sur le net, si le réseau en question permet de sortir. Non ? (pas taper).
pierre
-- Pierre LALET -- http://www.enseirb.fr/~lalet Clé publique PGP : http://www.enseirb.fr/~lalet/pierre_lalet.asc Empreinte de la clé : B6B8 0F89 2220 DF8B 0F3B C0C0 773E 15E6 A878 FC7E
Oui, mais là, il faut une machine sur le réseau filaire, c'est quand
même vachement contraignant, non ?
Je vais peut-être (surement même, vu que tu sembles sur de toi, mais
j'ai même pas peur) dire une bêtise, mais tu peux te contenter d'avoir
une machine sur le net, si le réseau en question permet de sortir.
Non ? (pas taper).
pierre
--
Pierre LALET
lalet@enseirb.fr -- http://www.enseirb.fr/~lalet
Clé publique PGP : http://www.enseirb.fr/~lalet/pierre_lalet.asc
Empreinte de la clé : B6B8 0F89 2220 DF8B 0F3B C0C0 773E 15E6 A878 FC7E
Oui, mais là, il faut une machine sur le réseau filaire, c'est quand même vachement contraignant, non ?
Je vais peut-être (surement même, vu que tu sembles sur de toi, mais j'ai même pas peur) dire une bêtise, mais tu peux te contenter d'avoir une machine sur le net, si le réseau en question permet de sortir. Non ? (pas taper).
pierre
-- Pierre LALET -- http://www.enseirb.fr/~lalet Clé publique PGP : http://www.enseirb.fr/~lalet/pierre_lalet.asc Empreinte de la clé : B6B8 0F89 2220 DF8B 0F3B C0C0 773E 15E6 A878 FC7E
