Evitar Deauth pois está causando latência alta a cada 20 segundos

Boa noite!

Após pensar que poderia ser alguma configuração no meu mikrotik, descobri que meu problema de ter latências altas a cada 20 segundos está relacionado a algum cliente ou tentativa não autorizada de acesso a minha rede.

Quando meu log do mikrotik começa a registrar estas linhas começa a latência na rede:
01:29:07 wireless,info : data from unknown device 00:40:F4:FB:B3:56, sent deauth (18 events suppressed, 48 deauths suppressed)
01:29:07 wireless,info : data from unknown device 00:40:F4:FB:B3:56, sent deauth
01:29:07 wireless,info : data from unknown device 00:40:F4:FB:B3:56, sent deauth
01:29:07 wireless,info : data from unknown device 00:40:F4:FB:B3:56, sent deauth
01:29:27 wireless,info : data from unknown device 00:40:F4:FB:B3:56, sent deauth (17 events suppressed, 38 deauths suppressed)
01:29:27 wireless,info : data from unknown device 00:40:F4:FB:B3:56, sent deauth
01:29:27 wireless,info : data from unknown device 00:40:F4:FB:B3:56, sent deauth
01:29:27 wireless,info : data from unknown device 00:40:F4:FB:B3:56, sent deauth (10 events suppressed, 8 deauths suppressed)
01:29:46 wireless,info : data from unknown device 00:40:F4:FB:B3:56, sent deauth (8 events suppressed, 41 deauths suppressed)
01:29:46 wireless,info : data from unknown device 00:40:F4:FB:B3:56, sent deauth
01:29:46 wireless,info : data from unknown device 00:40:F4:FB:B3:56, sent deauth
01:29:47 wireless,info : data from unknown device 00:40:F4:FB:B3:56, sent deauth (14 events suppressed, 26 deauths suppressed)

Normalmente algo em torno de 20 segundos. Aí todos meu clientes tem 17 pings em até 5ms e 3 entre 700ms e 3000ms.

Sexta-feira troquei um rádio de um cliente e o problema naquele dia foi resolvido, agora, conforme o log acima, este MAC não é de nenhum cliente meu e acredito que seja alguma forma de ataque DeAuth, pois li vários outros relatos de problemas com deauth e o MAC iniciava também com 00:40:F4, só pode ser algum software que utilizam pra quebrar WPA ou algo do tipo.

O que não entendo é que já cadastrei este MAC no access-list, impedindo-o de conectar, mas isto não evita estas entradas no log. Estou com receio de que passe a sofrer vários destes supostos problemas/ataques, simultâneos e não mais tenha latências altas somente a cada 20 segundos, mas sim o tempo todo.

Alguém tem alguma idéia de como resolver isto? Obrigado a todos e tenham uma ótima noite.

Só pra reforçar que tambem tenho a mesma duvida e gostaria que alguem que Soubesse do assunto, explicasse mais sobre e como evitar e se tem jeito de evitar..

:thrasher:

:shakehands:

:adore:

Ataque de Deauth é um problema sério e uma falha, sem correção, do protocolo 802.11. O única coisa que pode fazer é: SENTA E CHORA!

Não existe proteção para este ataque, pois ocorre no enlace (camada 2). Criptografia não resolve, autenticação não resolve, enfim nada que possa fazer.

Usando protocolos proprietários como nstreme, ror, cor, clocking de freqüência (10 e 5 Mhz), atualmente, consegue-se imunidade ao mesmo. Mas para isso toda a rede (clientes) deverão compartilhar das mesmas configurações.

PS. Luizbe, só lembrando, como está usando e vendendo pelo que vi, os nano station, os mesmos tem suporte a clocking.

:dancing:
sergio,
obrigado,

qual solução você usa?

Citação:

Postado originalmente por luizbe

:dancing:
sergio,
obrigado,

qual solução você usa?

Motorola Canopy, RB Cliente e AP em clocking ou nstreme e assim que homologar os nano-station.

mais uma perguntinha, como faço pra saber se ele ta usando o clocking ou não?
como configuro isso nos AP's? :)

Citação:

Postado originalmente por luizbe

mais uma perguntinha, como faço pra saber se ele ta usando o clocking ou não?
como configuro isso nos AP's? :)

clocking são aquelas conf de 10 ou 5 mhz do Mikrotik, por exemplo. Varios sistemas, que utilizam atheros dão suporte ao mesmo, variando o nome apenas. Desta forma basta apenas o AP e cliente suportarem essa conf.

Barbaridade! Simplesmente não dá pra acreditar que seja um problema ser solução. Minha cidade é pequena e volta e meia enfrento isto, imagina quem tem torres em cidades com mais população que a minha que é de 6000 habitantes no centro e duvido que existam mais 300 computadores com algum sistema wireless.

Desculpe Sérgio, mas é difícil aceitar que simplesmente não poderei oferecer um serviço decente a meus clientes a não ser que tenha que fazer com que todos troquem seus equipamentos.

Desculpe, mas vou continuar tentando encontrar alguma forma de contornar os efeitos, se não posso evitar a causa. Pelo menos gostaria que meu mikrotik na torre não sofresse latência na comunicação por causa disto. Como disse, se tenho 3 segundos de latência a cada 20 quando ocorre este DeAuth de uma origem (acredito), se houver 5 ou 6 ataques simultaneos simplesmente fico com um serviço podre.

Obrigado

Da uma olhada cara se o problema de deauth e de seus clientes ou de tentativa de invasao .. pois o mk tem varios problemas e esse e um deles..

Flavio,

ativa o "Periodic Calibration" ou desative-o pra ver.. :)

aqui eu fiz isso e amenizo BEM o Deauth.

e sergio, obrigado por dizer, tô testando uma torre 5.8 e já vo aplicar o mesmo :P

Fiz isto, tava com periodic-calibration=enable, troquei para disable mas não mudou em nada, então voltei para enable. To às catas para solução do problema ainda. Obrigado pela ajuda.

Citação:

Postado originalmente por flaviomreis

Barbaridade! Simplesmente não dá pra acreditar que seja um problema ser solução. Minha cidade é pequena e volta e meia enfrento isto, imagina quem tem torres em cidades com mais população que a minha que é de 6000 habitantes no centro e duvido que existam mais 300 computadores com algum sistema wireless.

Desculpe Sérgio, mas é difícil aceitar que simplesmente não poderei oferecer um serviço decente a meus clientes a não ser que tenha que fazer com que todos troquem seus equipamentos.

Desculpe, mas vou continuar tentando encontrar alguma forma de contornar os efeitos, se não posso evitar a causa. Pelo menos gostaria que meu mikrotik na torre não sofresse latência na comunicação por causa disto. Como disse, se tenho 3 segundos de latência a cada 20 quando ocorre este DeAuth de uma origem (acredito), se houver 5 ou 6 ataques simultaneos simplesmente fico com um serviço podre.

Obrigado

Flavio, infelizmente este é um problema de arquitetura, ou seja, do padrão 802.11 (culpa do IEEE, hehehehehehehe). Não é inerente a uma marca ou modelo de equipamento ou a algum sistema operacional em si. O problema é que os dados de enlace (MACs) correm livres pelo espectro/ar (sem cripto ou qualquer outra proteção), desta forma o atacante simplesmente precisa enviar um pedido de deauth, com o MAC de um cliente ou em alguns casos, usando aireplay nem isso precisa (apenas enviar o pedido de deauth). Como resolver? Usando protocolos e padrões proprietários, onde as conexões (enlace) são tratados de maneira diferente ou simplesmente o atacante não tem o mesmo equipamento com as mesmas configurações da sua rede.

Citação:

Postado originalmente por sergio

Flavio, infelizmente este é um problema de arquitetura, ou seja, do padrão 802.11 (culpa do IEEE, hehehehehehehe). Não é inerente a uma marca ou modelo de equipamento ou a algum sistema operacional em si. O problema é que os dados de enlace (MACs) correm livres pelo espectro/ar (sem cripto ou qualquer outra proteção), desta forma o atacante simplesmente precisa enviar um pedido de deauth, com o MAC de um cliente ou em alguns casos, usando aireplay nem isso precisa (apenas enviar o pedido de deauth). Como resolver? Usando protocolos e padrões proprietários, onde as conexões (enlace) são tratados de maneira diferente ou simplesmente o atacante não tem o mesmo equipamento com as mesmas configurações da sua rede.

Totalmente Correto!

O deauth (Rede DOS) consiste numa inundação em redes sem fio com pacotes deauthentication ou BSSID falsificados tentando realizar uma autenticação de estações não autorizadas!

Ná realidade existem varias formas, posso citar algo similiar ;

- Realizar uma tentativa de controlar os Frames ( 802.11 ), para causar um "busy out" em um canal, para que nenhuma outra estação se conecte ( Chamamos de DoS Queensland )
- Usar deauthenticate frames para desligar uma estação em especial, enviando um fluxo continuo destes quadros falsificados ( Chamamos de Deauth Flood )
- Se associar ao AP, gerar frames alterando a tabela de associação, causando um lag, prejudicando os recursos do AP/
- Entre outros, simulando pacotes forjados, tipo 802.1X EAP logoff Flood, PAA Start Flood, e EAP-de-Morte ataques.

Valeu galera!

*Lembrando que falamos em questão de 802.11XX IEEE

Então Felipe e Sergio, vocês usam estes equipamentos proprietários em todos os clientes ou tiveram a sorte de não conviver com este problema?

Citação:

Postado originalmente por flaviomreis

Então Felipe e Sergio, vocês usam estes equipamentos proprietários em todos os clientes ou tiveram a sorte de não conviver com este problema?

Os equipamentos que uso citei lá em cima. São todos proprietários (apesar que utilizar sub-faixas -5/10 Mhz- não é tão proprietário assim).
:stickyman:

Sergio vc pode dar mais detalhes sob o clocking ??

Citação:

Postado originalmente por admskill

Sergio vc pode dar mais detalhes sob o clocking ??

uai?.. que detalhes? é simples, o padrão de transmissão de todos esses equipamentos wifi são 20 Mhz. Alguns chipsets como atheros, permitem que você divida esta faixa em sub-faixas, de 10 Mhz ou 5 Mhz ou ainda o modo turbo que é 40 Mhz. Teoricamente, estreitando a faixa de transmissão você tem menos banda e alargando tem mais banda. Digo teoricamente, pois em caso de interferencia, a banda despenca e fazendo o clocking para 5 Mhz por exemplo, acaba fugindo da mesma, pois a faixa "escuta" menos a interferência e com isso normalmente aumenta-se a banda. O contrário vale para o modo turbo.

De quebra você ganha "imunidade" contra ataque de deauth, pois esta configuração não permite que equipamentos utilizando o padrão (20 MHz) troque informações na rede.