Le réseau sans fil semble avoir été compromis et sera désactivé pendant environ une minute

Je viens de recevoir un message sur mon système Mac OS X me disant:

Le réseau sans fil semble avoir été compromis et sera désactivé pendant environ une minute. ^†

(Il s'agit d'un réseau sans fil sécurisé WPA2-PSK sans fil BTW)

Exemple de message:

J'ai regardé dans les journaux de mon routeur (un Zyxel P-2602HW-D1A) seulement pour voir quelques journaux (sortants) "syn flood TCP ATTACK", mais ceux-ci datent d'il y a une semaine, à part ça rien. Quels outils sur Mac OS X dois-je pour analyser cette occurrence de violation de sécurité? Existe-t-il des journaux de sécurité sur Mac OS X que je peux inspecter?

Quelles autres mesures dois-je prendre? Et dans quelle mesure dois-je prendre cet avertissement de Mac OS X?

Système : Macbook Pro Intel Core 2 Duo 2.2 Ghz
OS : Mac OS X 10.5.8
Réseau : sans fil WPA2-PSK
Logiciel pertinent : Parallels Desktop avec Windows XP (était ouvert, mais arrêté à l'époque)

Autres systèmes sur mon réseau:
bureau Windows XP SP3 (fonctionnait à l'époque)

Si vous avez besoin de plus d'informations, n'hésitez pas à demander.

^† Le message réel était en néerlandais, probablement quelque chose comme le suivant de /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/ ClientController.bundle / Contents / Resources / Dutch.lproj :

Het draadloze netwerk wordt gedurende ongeveer een minuut uitgeschakeld omdat de beveiliging ervan is aangetast.

C'est le message que vous obtenez lorsque la carte / le pilote AirPort détecte deux échecs TKIP "MIChael" MIC (Message Integrity Check) dans les 60 secondes, ou est informé de ces échecs par l'AP.

Le cryptage TKIP, qui était la base du WPA d'origine et peut toujours être activé sous WPA2 dans ce qui est connu sous le nom de "Mode mixte WPA2", avait une faible probabilité de défaillances MIC aléatoires, mais deux défaillances dans les 60 secondes sont trop peu susceptibles d'être aléatoires, donc la spécification WPA le traite comme une attaque et nécessite que le réseau tombe en panne pendant une minute ou deux pour contrecarrer les attaquants.

Le cryptage AES-CCMP qui est à la base de WPA2 a également un MIC (enfin, ils l'appellent un MAC - Message Authentication Check - c'est le «M» de CCMP), mais je ne me souviens pas du haut de ma tête ce qui est censé se produire s'il y a une panne MAC AES-CCMP Je ne pense pas que cela implique de couper temporairement le réseau.

De loin, le scénario le plus probable est que vous venez de frapper un bogue où le point d'accès ou le client a gâché sa gestion MIC, ou où le code de gestion des échecs MIC a été accidentellement déclenché.

J'ai vu des cartes sans fil avoir des bugs dans ce domaine, en particulier en mode promiscuous. Vous voudrez peut-être vous assurer que Parallels ou autre chose ne met pas votre carte sans fil en mode promiscuous. Exécutez ifconfig en1(si en1 est votre carte AirPort, comme c'est généralement le cas) et recherchez dans la liste des indicateurs d'interface ("UP, BROADCAST ...") le drapeau PROMISC. Certains logiciels VM utilisent le mode Promiscuous pour activer la mise en réseau "pontée" ou "partagée", au moins pour les interfaces Ethernet câblées. Étant donné que de nombreuses cartes sans fil ne gèrent pas bien le mode promiscuous, la plupart des logiciels VM modernes prennent soin de ne pas mettre une interface sans fil en mode promiscuous.

Il est possible, mais peu probable, que quelqu'un vous dérange en forgeant une trame d'authentification 802.11 avec le code de motif pertinent, que le client a ensuite consciencieusement signalé dans la pile.

Le scénario de loin le moins probable est que quelqu'un lançait réellement une attaque sur votre réseau.

Si le problème se reproduit, une trace de paquets en mode moniteur 802.11 est probablement le meilleur moyen d'enregistrer l'attaque. Mais je pense qu'expliquer comment faire une bonne trace de paquets en mode moniteur 802.11 sous 10.5.8 dépasse le cadre de cette réponse. Je mentionnerai que cela /var/log/system.logpourrait vous en dire plus sur ce que le logiciel client / pilote AirPort a vu à l'époque, et vous pouvez augmenter un peu le niveau de journal avec

sudo /usr/libexec/airportd -d

Snow Leopard a une bien meilleure journalisation du débogage AirPort, donc si vous passez à Snow Leopard, la commande est:

sudo /usr/libexec/airportd debug +AllUserland +AllDriver +AllVendor

Renifler est facile sur Snow Leopard:

sudo /usr/libexec/airportd en1 sniff 1

(Cet exemple suppose que votre carte AirPort est en1 et que votre point d'accès est sur le canal 1.)

Selon ce fil , le message provient du pilote AirPort lorsqu'il détecte un problème avec la vérification d'intégrité du message TKIP ou la somme de contrôle associée.

Donc, fondamentalement, soit votre réseau est compromis par des attaques par injection TKIP , soit simplement le routeur calcule incorrectement le MIC ou la somme de contrôle, soit les paquets sont corrompus pendant la transmission en raison des interférences d'un autre routeur fonctionnant sur des plages de fréquences similaires .

La manière suggérée d'éviter cela est de passer à un autre routeur ou, si possible, d'utiliser uniquement le cryptage WPA2.

Voir: Comment éviter l'attaque standard de sécurité sans fil WPA?

TKIP a été créé comme une solution rapide pour les anciens points d'accès et clients qui étaient paralysés par WEP. Au lieu d'utiliser la même clé pour crypter chaque paquet, TKIP utilise RC4 avec une clé différente pour chaque paquet. Ces clés par paquet neutralisent les crackers de cryptage WEP. De plus, TKIP utilise un contrôle à clé de l'intégrité des messages (MIC) pour détecter les paquets qui sont relus ou falsifiés. N'importe qui peut envoyer (c'est-à-dire injecter) un paquet chiffré TKIP qui a été capturé et modifié, mais ces paquets sont supprimés car le MIC et la somme de contrôle ne correspondent pas aux données transportées par le paquet. Les points d'accès utilisant TKIP transmettent généralement un rapport d'erreur lorsque le premier mauvais MIC est reçu.Si un deuxième mauvais paquet arrive dans les 60 secondes, l'AP cesse d'écouter pendant une autre minute puis "rekeys" le WLAN, obligeant tous les clients à commencer à utiliser une nouvelle "clé principale par paire" pour générer à la fois la clé MIC et le chiffrement par paquet clés.

Cela a bouché les trous béants laissés par le WEP. Tous les produits certifiés WPA peuvent utiliser TKIP et son MIC pour résister aux attaques d'écoute, de falsification et de relecture de données 802.11.