Essa é a mensagem que você recebe quando o cartão / driver AirPort detecta duas falhas do TKIP "MIChael" MIC (Message Integrity Check) dentro de 60 segundos ou é notificado pelo AP.
A criptografia TKIP, que foi a base do WPA original e ainda pode ser ativada no WPA2 no que é conhecido como "Modo Misto WPA2", tinha uma pequena probabilidade de falhas aleatórias na MIC, mas é improvável que duas falhas em 60 segundos sejam aleatórias. a especificação WPA trata isso como um ataque e exige que a rede seja desativada por um minuto ou dois para impedir invasores.
A criptografia AES-CCMP, que é a base do WPA2, também possui um MIC (bem, eles o chamam de MAC - Message Authentication Check - é o 'M' do CCMP), mas não me lembro de nada disso. encabece o que deveria acontecer se houver uma falha no MAC da AES-CCMP. Eu não acho que isso envolve abater a rede temporariamente.
De longe, o cenário mais provável é que você encontrou algum bug em que o AP ou o cliente estragou sua manipulação de MIC ou o código de manipulação de falha de MIC foi acionado acidentalmente.
Já vi placas sem fio com bugs nessa área, principalmente em modo promíscuo. Convém garantir que a Parallels ou outra coisa não esteja colocando sua placa sem fio no modo promíscuo. Execute ifconfig en1
(se en1 for sua placa AirPort, como normalmente é) e procure na lista de sinalizadores da interface ("UP, BROADCAST ...") pelo sinalizador PROMISC. Alguns softwares de VM usam o modo Promíscuo para ativar a rede "em ponte" ou "compartilhada", pelo menos para interfaces Ethernet com fio. Como muitas placas sem fio não lidam bem com o modo promíscuo, a maioria dos softwares VM modernos tem o cuidado de não colocar uma interface sem fio no modo promíscuo.
É possível, mas improvável, que alguém estivesse mexendo com você, forjando um quadro de autenticação de 802.11 com o código de razão relevante, que o cliente então obedientemente relatou na pilha.
De longe, o cenário menos provável é que alguém realmente estivesse lançando um ataque à sua rede.
Se o problema ocorrer novamente, um rastreamento de pacotes no modo de monitor 802.11 é provavelmente a melhor maneira de registrar o ataque. Mas acho que explicar como executar um bom rastreamento de pacotes no modo de monitor 802.11 sob 10.5.8 está além do escopo desta resposta. Mencionarei que /var/log/system.log
pode lhe contar mais sobre o que o software cliente / driver AirPort viu na época e você pode aumentar um pouco o nível de log com
sudo /usr/libexec/airportd -d
O Snow Leopard possui um registro de depuração AirPort muito melhor; portanto, se você atualizar para o Snow Leopard, o comando é:
sudo /usr/libexec/airportd debug +AllUserland +AllDriver +AllVendor
Cheirar é fácil no Snow Leopard:
sudo /usr/libexec/airportd en1 sniff 1
(Esse exemplo assume que sua placa AirPort é en1 e seu AP está no canal 1.)