OVH Cloud OVH Cloud

A propos du 802.1x

10 réponses
Avatar
Bruno Bonfils
Bonjour,

j'hésite de plus en plus à mettre du 802.1x sur le parc utilisateur,
néanmoins, ne disposant bien évidemment pas de switch manageable à
tous les niveaux, je me demande si cela est vraiment intéressant ou
pas.

Petit schéma :

--------------
| SW L2 802.1x |
--------------
| |
| |
----- -----
| SW8 | | SW8 |
----- -----
| | | | | | | |
----------------------
Users

Comme vous le voyez, les utilisateurs sont connectés au switch qui
fait du 802.1x via des switch (de merde) 8 ports.

Ma question est : est ce possible d'avoir plusieurs authentifications
802.1x sur un seul port ? (Si c'est pas le cas mon problème est vite
réglé).

Si cela peut fonctionner, je me demande dans quelles mesures c'est
vraiment sécuritaire. Certes, cela évite que le premier venu branche
son portable, mais j'aurais aimé avoir votre avis.

Merci d'avance

--
\_o<

10 réponses

Avatar
Cedric Blancher
Le Tue, 07 Jun 2005 08:16:04 +0000, Bruno Bonfils a écrit :
Ma question est : est ce possible d'avoir plusieurs authentifications
802.1x sur un seul port ? (Si c'est pas le cas mon problème est vite
réglé).


Non.
Le port du switch devra d'une part être configuré comme port recevant
plusieurs postes, mais le premier qui va s'authentifier va ouvrir le-dit
port pour tout le monde. C'est une technique classique pour brancher un
poste sur un réseau 802.1x que de débrancher un poste légitime, le
plugger sur un hub (ou un switch), plugger le hub sur la prise. Le poste
va se réauthentifier et ouvrir le port, il ne reste plus qu'à se
brancher sur le hub pour entrer.

C'est pourquoi il me semble indispensable, lorsqu'on déploie 802.1x de
veiller à ne configurer les ports pour n'accepter qu'une seule machine
après authentification, et positionner de la port security si les postes
sont fixes.

Si cela peut fonctionner, je me demande dans quelles mesures c'est
vraiment sécuritaire. Certes, cela évite que le premier venu branche
son portable, mais j'aurais aimé avoir votre avis.


Ça peut fonctionner en effet, mais si le premier venu équipé de son
portable arrive alors qu'un poste sur le même switch est authentifié et
allumé, alors il va passer. Si en outre tu fais de l'affectation de VLAN
via 802.1x, ça va vraiment devenir le bordel, tout le monde se retrouvant
dans le VLAN du premier authentifié :)


--
CS: Oui mais alors moi je me construis une souris avec autant de boutons
qu'applis et je fais des racourcis, rena ! :-)
LP: Ah oui, mais alors là il va falloir acheter des doigts, rerena! ;-p
-+- LP in Guide du Macounet Pervers : Vous m'en mettrez une poignée -+-

Avatar
Bruno Bonfils
Cedric Blancher writes:

Non.

Le port du switch devra d'une part être configuré comme port recevant
plusieurs postes, mais le premier qui va s'authentifier va ouvrir le-dit
port pour tout le monde. C'est une technique classique pour brancher un
poste sur un réseau 802.1x que de débrancher un poste légitime, le
plugger sur un hub (ou un switch), plugger le hub sur la prise. Le poste
va se réauthentifier et ouvrir le port, il ne reste plus qu'à se
brancher sur le hub pour entrer.


Ah, bon, c'est triste. Ce qui m'amene a la question qui tue, comment
ils font les gens pour faire du 802.1x dans une entreprise avec plein
de salariés ou on peut avoir chaque switch de brassage qui fasse du
802.1x ? Snif snif, je vais me contenter de filtrage MAC

Merci à toi Cédric (as usual :)

--
_o<

Avatar
Cedric Blancher
Le Tue, 07 Jun 2005 12:54:00 +0000, Bruno Bonfils a écrit :
Ah, bon, c'est triste.


Oui, un peu.
Mais si on faisait ce que tu veux faire, ça deviendrait rapidement une
véritable usine à gaz qui tiendrait plus du firewall de niveau 2 que du
switch.

Ce qui m'amene a la question qui tue, comment ils font les gens pour
faire du 802.1x dans une entreprise avec plein de salariés ou on peut
avoir chaque switch de brassage qui fasse du 802.1x ?


Ils font comme toi, ils pleurent.


--
BOFH excuse #314:

You need to upgrade your VESA local bus to a MasterCard local bus.

Avatar
Sylvain Eche
Jsuis pas tout a fait d'accord ...

dans les switchs cisco et nortel, il existe une fonction multi host /
multi port ou un truc du genre (regarder dans la doc 802.1x de nortel ou
cisco pour vérifier le nom exact ...) pour pouvoir gérer plusieurs
adresses mac derrière le même port physique.
C'est le même principe en wifi ou on est en média partagé.

Le principe consiste a faire plusieurs ports virtuels sur un port
physique en utilisant les adresses MAC. ce qui fait que chaque
utilisateur doit s'authentifier.

Par contre ce genre de chose a des limites car au niveau du switch une
attaque par spoofing de mac est théoriquement possible.
En wifi, le chiffrement des trames rend l'usurpation MAC impossible car
l'attaquant n'a pas la clé WEP ou TKIP.




Ah, bon, c'est triste.



Oui, un peu.
Mais si on faisait ce que tu veux faire, ça deviendrait rapidement une
véritable usine à gaz qui tiendrait plus du firewall de niveau 2 que du
switch.


Ce qui m'amene a la question qui tue, comment ils font les gens pour
faire du 802.1x dans une entreprise avec plein de salariés ou on peut
avoir chaque switch de brassage qui fasse du 802.1x ?



Ils font comme toi, ils pleurent.





Avatar
Cedric Blancher
Le Wed, 08 Jun 2005 09:35:07 +0000, Sylvain Eche a écrit :
dans les switchs cisco et nortel, il existe une fonction multi host /
multi port ou un truc du genre (regarder dans la doc 802.1x de nortel ou
cisco pour vérifier le nom exact ...) pour pouvoir gérer plusieurs
adresses mac derrière le même port physique.


Je ne sais pas chez Nortel, mais chez Cisco, la documentation des 6500 dit
le contraire en IOS 12.2X et 12.2(14)SY:

http://www.cisco.com/en/US/products/hw/switches/ps708/products_configuration_guide_chapter09186a0080160a04.html#1025995
http://www.cisco.com/en/US/products/hw/switches/ps708/products_configuration_guide_chapter09186a008017957f.html#1025995


Configuring 802.1X Port-Based Authentication
[...]
Enabling Multiple Hosts

You can attach multiple hosts to a single 802.1X-enabled port as shown in
Figure 25-3. In this mode, only one of the attached hosts must be
successfully authorized for all hosts to be granted network access. If
the port becomes unauthorized (reauthentication fails or an EAPOL-logoff
message is received), all attached clients are denied access to the
network.

Nortel le fait peut-être, ce qui est une bonne chose, mais il faut alors
faire extrêmement attention à comment on le fait. En effet, EAP-MD5
peut-être très facilement attaqué (c'est pour ça, entre autres, qu'il
ne doit pas être utilisé en WiFi). Les échanges EAP doivent alors être
chiffrés (PEAP ou EAP-TTLS) ou échanger des informations publiques
(EAP-TLS).

C'est le même principe en wifi ou on est en média partagé.


C'est un peu faux ça.

Le médium est certes partagé, mais on introduit d'autres notions de
niveau 2. La notion de port sur un réseau ethernet switché est émulé
par la notion d'association. Un AP pour un réseau WiFi est un pont entre
les associations qu'il gère. De fait, en WiFi, chaque authentification
est liée à une association, et c'est l'AP qui les gère, exactement
comme un switch gère ses ports.

Par contre ce genre de chose a des limites car au niveau du switch une
attaque par spoofing de mac est théoriquement possible.


Tout à fait.

En wifi, le chiffrement des trames rend l'usurpation MAC impossible car
l'attaquant n'a pas la clé WEP ou TKIP.


Faux. Ce n'est pas la non-connaissance de la clé qui empêche cela, et
surtout pas en WEP.

La connaissance de la clé n'est pas nécessaire pour générer du trafic
avec un adresse MAC donnée. Le rejeu en est un exemple parfait. En WEP,
c'est trivial. Pour TKIP, le mécanisme de contrôle d'intégrité
intégrant un mécanisme anti-rejeu, on n'y arrive pas. Mais ça n'a rien
à voir avec la connaissance de la clé.

Exemple simple : l'attaque d'une clé WEP par rejeu de trafic ARP...

Enfin, si on utilise un MAC qui n'existe pas, c'est l'absence
d'association qui nous empêchera de discuter avec l'AP et ce qu'il y a
derrière, la communication sur le LAN restant possible par injection de
trafic, en clair ou en WEP, comme je l'ai montré au SSTIC durant la rump.
Les slides (également en ligne sur le site du SSTIC) sont là :

http://sid.rstack.org/pres/0506_SSTIC_Wifitap.pdf

Le PoC sera en ligne la semaine prochaine (pour la Recon2005).


--
SUITE À DE NOMBREUSES TENTATIVES D'INTRUSIONS SUR MA MACHINE SUR LE PORT 80
Meuh non, pour tous vos problèmes de peau , Biactol.fr est le seul site

qui débouche tous vos ports, même le port 80...
-+- Yûsei in Guide du Fmblien Assassin : la crème de la sécurité -+-

Avatar
Jerometemp
Bonjour,


Je peux te conseille d 'utiliser www.nufw.org qui a une approche
différente (filtrage des utilisateurs authentifiés et pas des Mac ou
IPs) . Tu pourras très facilement n'autoriser que les flux authentifiés
à passer donc personne ne viendra squatter ton réseau (ils pourront se
connecter mais ne pourront rien faire).




Bonjour,

j'hésite de plus en plus à mettre du 802.1x sur le parc utilisateur,
néanmoins, ne disposant bien évidemment pas de switch manageable à
tous les niveaux, je me demande si cela est vraiment intéressant ou
pas.

Petit schéma :

--------------
| SW L2 802.1x |
--------------
| |
| |
----- -----
| SW8 | | SW8 |
----- -----
| | | | | | | |
----------------------
Users

Comme vous le voyez, les utilisateurs sont connectés au switch qui
fait du 802.1x via des switch (de merde) 8 ports.

Ma question est : est ce possible d'avoir plusieurs authentifications
802.1x sur un seul port ? (Si c'est pas le cas mon problème est vite
réglé).

Si cela peut fonctionner, je me demande dans quelles mesures c'est
vraiment sécuritaire. Certes, cela évite que le premier venu branche
son portable, mais j'aurais aimé avoir votre avis.

Merci d'avance



Avatar
Sylvain Eche
Ah de la résistance !!

apres verification il semblerait que selon le slide
http://www.cisco.com/warp/public/732/Tech/security/docs/8021xoverview.ppt

le multiple-auth support soit depuis l'IOS 12.3(4)
enfin cet IOS semble dater de fin 2003

chez nortel ils appelent ca multiple host multiple authentication.
C'est absolument necessaire dans certains cas :
telephone IP + pc relié sur le telephone (y a aussi le fait que les
telephones IP sont pas encore 802.1x compliant ...)
ou station VMware avec serveurs mutualisés avec pleins d'adresses MAC ...

En wifi, le chiffrement des trames rend l'usurpation MAC impossible car
l'attaquant n'a pas la clé WEP ou TKIP.



Faux. Ce n'est pas la non-connaissance de la clé qui empêche cela, et
surtout pas en WEP.


on s'est mal compris ...

je voulais préciser que le 802.1X tout seul en wifi n'apporte aucune
protection puisque l'authentification perdure de par l'adresse MAC.
en éthernet, une coupure physique permet de détecter la dessassociation,
en wifi ou en ethernet multiple host, multiple authentication cette
coupure physique n'est plus la comme garde fou.

Pour un réseau wifi protégé uniquement par du 802.1x (sans
chiffrement)ou en multiple host, multiple authentication, il suffit
juste de spoofer l'adresse Mac d'une personne authentifié et on passe.
Il est absolument necessaire d'avoir en plus un chiffrement associé du
TKIP ou du CCMP (pas du WEP ok ...) qui ne va pas empécher de spoofer
l'adresse MAC, mais va constituer une barrière car l'attaquant n'aura
pas la clef et sera rejetté ...



dans les switchs cisco et nortel, il existe une fonction multi host /
multi port ou un truc du genre (regarder dans la doc 802.1x de nortel ou
cisco pour vérifier le nom exact ...) pour pouvoir gérer plusieurs
adresses mac derrière le même port physique.



Je ne sais pas chez Nortel, mais chez Cisco, la documentation des 6500 dit
le contraire en IOS 12.2X et 12.2(14)SY:

http://www.cisco.com/en/US/products/hw/switches/ps708/products_configuration_guide_chapter09186a0080160a04.html#1025995
http://www.cisco.com/en/US/products/hw/switches/ps708/products_configuration_guide_chapter09186a008017957f.html#1025995


Configuring 802.1X Port-Based Authentication
[...]
Enabling Multiple Hosts

You can attach multiple hosts to a single 802.1X-enabled port as shown in
Figure 25-3. In this mode, only one of the attached hosts must be
successfully authorized for all hosts to be granted network access. If
the port becomes unauthorized (reauthentication fails or an EAPOL-logoff
message is received), all attached clients are denied access to the
network.

Nortel le fait peut-être, ce qui est une bonne chose, mais il faut alors
faire extrêmement attention à comment on le fait. En effet, EAP-MD5
peut-être très facilement attaqué (c'est pour ça, entre autres, qu'il
ne doit pas être utilisé en WiFi). Les échanges EAP doivent alors être
chiffrés (PEAP ou EAP-TTLS) ou échanger des informations publiques
(EAP-TLS).


C'est le même principe en wifi ou on est en média partagé.



C'est un peu faux ça.

Le médium est certes partagé, mais on introduit d'autres notions de
niveau 2. La notion de port sur un réseau ethernet switché est émulé
par la notion d'association. Un AP pour un réseau WiFi est un pont entre
les associations qu'il gère. De fait, en WiFi, chaque authentification
est liée à une association, et c'est l'AP qui les gère, exactement
comme un switch gère ses ports.


Par contre ce genre de chose a des limites car au niveau du switch une
attaque par spoofing de mac est théoriquement possible.



Tout à fait.


En wifi, le chiffrement des trames rend l'usurpation MAC impossible car
l'attaquant n'a pas la clé WEP ou TKIP.



Faux. Ce n'est pas la non-connaissance de la clé qui empêche cela, et
surtout pas en WEP.

La connaissance de la clé n'est pas nécessaire pour générer du trafic
avec un adresse MAC donnée. Le rejeu en est un exemple parfait. En WEP,
c'est trivial. Pour TKIP, le mécanisme de contrôle d'intégrité
intégrant un mécanisme anti-rejeu, on n'y arrive pas. Mais ça n'a rien
à voir avec la connaissance de la clé.

Exemple simple : l'attaque d'une clé WEP par rejeu de trafic ARP...

Enfin, si on utilise un MAC qui n'existe pas, c'est l'absence
d'association qui nous empêchera de discuter avec l'AP et ce qu'il y a
derrière, la communication sur le LAN restant possible par injection de
trafic, en clair ou en WEP, comme je l'ai montré au SSTIC durant la rump.
Les slides (également en ligne sur le site du SSTIC) sont là :

http://sid.rstack.org/pres/0506_SSTIC_Wifitap.pdf

Le PoC sera en ligne la semaine prochaine (pour la Recon2005).





Avatar
Cedric Blancher
Le Wed, 08 Jun 2005 22:48:39 +0000, Sylvain Eche a écrit :
Ah de la résistance !!


En effet.

le multiple-auth support soit depuis l'IOS 12.3(4)
enfin cet IOS semble dater de fin 2003


Effectivement, au temps pour moi. Pour la doc trouvée chez Cisco, elle
était datée d'avril dernier... pour un IOS vieux de 3 ans...
Je vais revenir bosser mon 802.1x filaire :)

Pour un réseau wifi protégé uniquement par du 802.1x (sans
chiffrement) ou en multiple host, multiple authentication, il suffit
juste de spoofer l'adresse Mac d'une personne authentifié et on passe.


Y'a des gens qui font du 802.1x et qui ne chiffrent pas derrière ?

Il est absolument necessaire d'avoir en plus un chiffrement associé du
TKIP ou du CCMP (pas du WEP ok ...) qui ne va pas empêcher de spoofer
l'adresse MAC, mais va constituer une barrière car l'attaquant n'aura
pas la clef et sera rejetté ...


Au risque de me répéter, ce n'est pas le chiffrement la barrière...

La non possession de la clé va l'empêcher de produire ses propres
paquets, mais elle lui permet encore de faire du rejeu, à moins qu'un
mécanisme anti-rejeu soit présent. Et c'est lui précisément qui
empêche en WPA/WPA2 d'injecter des trames rejouées, pas le chiffrement,
puisqu'on le rejoue.

La notion de rejeu est souvent sous-estimée, mais comme on l'a vu avec
Aircrack, c'est elle qui permet de casser des clés WEP. Et comme WPA/TKIP
s'appuie également sur RC4, il est heureux que la même méthode ne
puisse pas être appliquée en l'état ;)


--
BOFH excuse #59:

failed trials, system needs redesigned

Avatar
Bruno Bonfils
Jerometemp writes:

Bonjour,


Je peux te conseille d 'utiliser www.nufw.org qui a une approche
différente (filtrage des utilisateurs authentifiés et pas des Mac ou
IPs) . Tu pourras très facilement n'autoriser que les flux authentifiés
à passer donc personne ne viendra squatter ton réseau (ils pourront se
connecter mais ne pourront rien faire).


Oué mais ce genre de chose ca n'empeche pas du MitM par exemple ? Ce
qui m'intéresse c'est une protection niveau 2. Déjà que je comprend
pas pourquoi le 802.1x ca n'a pas prévu de base de pouvoir mettre
plusieurs utilisateurs authentifiés sur un port sans tout ouvrir (il
est vrai ca ne supprime pas tous les problèmes, mais quand même).

Sinon, merci pour vos réponses sur le 802.1x et cisco, je vais tester
ca tres prochainemement.


--
_o<

Avatar
Jerometemp
Jerometemp writes:

Bonjour,


Je peux te conseille d 'utiliser www.nufw.org qui a une approche
différente (filtrage des utilisateurs authentifiés et pas des Mac ou
IPs) .
Oué mais ce genre de chose ca n'empeche pas du MitM par exemple ?



Amha je ne vois pas pourquoi nufw serait + sensible qu une protection
niveau 2 pour une attaque de type MitM

Ce
qui m'intéresse c'est une protection niveau 2. Déjà que je comprend
pas pourquoi le 802.1x ca n'a pas prévu de base de pouvoir mettre
plusieurs utilisateurs authentifiés sur un port sans tout ouvrir (il
est vrai ca ne supprime pas tous les problèmes, mais quand même).

Sinon, merci pour vos réponses sur le 802.1x et cisco, je vais tester
ca tres prochainemement.