Isolement des clients sans fil - comment cela fonctionne-t-il et peut-il être contourné?
De nos jours, de nombreux routeurs SOHO prennent en charge une fonctionnalité appelée "isolation client sans fil" ou similaire. Ce que cela est censé faire, en principe, est de limiter la connectivité entre les clients sans fil connectés à l'AP. Les clients sans fil peuvent parler au LAN et accéder à Internet si une telle connexion est disponible, mais ils ne peuvent pas communiquer entre eux.
Comment y parvient-on? Existe-t-il des faiblesses particulières qui permettraient de contourner cela facilement?
L'implémentation que j'ai vue de cela se fait en jouant avec la table de transfert MAC sur le point d'accès. Étant donné que le point d'accès agit simplement comme un pont réseau, il est assez bien adapté à ce type de tâche. Au niveau de la couche de commutation, il collecte déjà tous les MAC entendus (parfois appelés appris) et sur quelle interface il peut être trouvé.
La logique ressemble un peu à ceci:
- Le point d'accès reçoit un paquet sur l'interface sans fil
- Le sous-système de pontage examine le paquet pour le MAC de destination
- Si le MAC de destination est dans la table de commutation apprise pour l'interface sans fil -> DROP
- Sinon, transférez le paquet via une interface filaire
En raison de la façon dont les ponts réseau fonctionnent, je vois qu'il est assez difficile de tromper le point d'accès pour qu'il transfère un paquet à un client malgré l'isolement. Le mieux serait de tenter de parler directement à l'autre client, comme si vous fonctionniez avec un réseau ad hoc.
Isolement des clients sans fil, comment cela fonctionne et comment il est contourné:
Lorsque vous établissez une connexion sans fil (wpa/wpa2-aes/tkip) avec votre point d'accès (AP/routeur), 2 clés sont créées, une clé unique pour le trafic unicast et une clé partagée pour le trafic de diffusion qui est partagée avec chaque PC qui se connecte , connu sous le nom de GTK.
Lorsque vous envoyez des données à l'AP, elles sont cryptées avec votre clé unicast. L'AP décrypte ensuite cela et utilise la diffusion GTK pour envoyer les données au système suivant sur le réseau sans fil.
Lorsque vous activez l'isolement du client sur l'AP, il cesse d'utiliser le GTK pour envoyer des données. Parce que tout le monde établit une clé de monodiffusion unique pour envoyer des données avec vous, vous ne pourrez plus voir les données des autres.
Contourner cela demande un peu plus d'efforts et de compréhension. Sachez que le trafic ARP est toujours diffusé sur le réseau à l'aide de GTK afin que DHCP puisse gérer les clients.
Si la table ARP est empoisonnée avec un MAC de diffusion sur l'entrée des clients, vous forcerez le système des clients à utiliser le bradcast GTK lors de l'envoi de données. Si le système client est trompé en utilisant le GTK pour envoyer des données, il peut maintenant être vu et vous contournez l'isolement du client.
Ainsi, si vous définissez votre entrée ARP statique locale en utilisant l'IP des clients avec un mac bradcast, votre système local pensera qu'il envoie du trafic de diffusion lorsqu'il parle à ce client et utilise le GTK permettant au client de voir votre trafic.
Il faudra environ deux minutes à DHCP pour corriger une entrée ARP empoisonnée, vous devrez donc écrire un programme qui diffuse des ARP empoisonnés/faux pour maintenir la visibilité.
Je reconnais que certains AP avancés ont un contrôle d'arp et une isolation de couche 2 où des tactiques avancées sont nécessaires, mais nous ne parlons pas de ces gars-là parlaient de votre SOHO.
À votre santé.