[GTER] "Clash" de canais no Wi-Fi.

Marcus Andree marcusandree em gmail.com
Sexta Junho 19 09:56:35 BRT 2009


Olha, nao me pareceu ser um uso direto do protocolo, "dentro das regras".

Colocava a placa em modo de testes, sem gerenciamento automatico de
potencia de transmissao e com controle de todos os canais RF, inclusive
algumas frequencias nao homologadas para este uso no territorio nacional,
mas autorizadas pelo governo japones.

Ao brincar um pouco de setar a potencia de transmissao "na unha", direto
no chipset, podia perceber que os micros conectados, inclusive em outros
access points, perdiam a conexao de rede instantaneamente. Tentativas
de reconexao se mostraram inuteis.

A verdadeira razao para isso ainda e' misteriosa para mim, razao pela qual
rotulei essa "funcionalidade" como "efeito colateral".

Por um mix de falta de tempo e de recursos (analisador de espectro), nao
fiz um diagnostico tecnico, mas suspeito que o chipset tenha perdido o
controle de qual frequencia seria transmitido o beacon da rede sem fio, bem
como o intervalo de tempo destas transmissoes, virtualmente jogando "lixo"
em frequencias fora do canal setado no equipamento, mas com potencia
suficiente para interferir nos outros aparelhos.

Os militares chamam isso de "contra-medidas" enquanto nos chamamos
de DoS....

2009/6/19 Hygor <hygort em gmail.com>

> Marcus essa "função" que você fez.. seria algo com deauth?
>
> Drivers e placas com problemas.. podem sim derrubar uma rede não somente
> wireless mais rede via cabo tb
>
>
> Hygor Cavalcante
> FSNetwork Consultoria
>
>
> 2009/6/19 Marcus Andree <marcusandree em gmail.com>
>
> > Sim, eh um belo exemplo de um DoS.
> >
> > 2009/6/19 Antonio Carlos Pina <antoniocarlospina em gmail.com>
> >
> > > Penso que seria uma bela apresentação para um GTS. Embora não seja
> > > "invasão", não deixa de ser um ataque que pode ser ativado por um
> > > funcionário deixando o administrador em maus lençóis.
> > >
> > > Abs
> > >
> > > 2009/6/19 Marcus Andree <marcusandree em gmail.com>
> > >
> > > > Ja comentei em algumas outras mensagens que construi um access point
> > > > para uso proprio, com um SBC Soekris rodando OpenBSD.
> > > >
> > > > Uma das tarefas que empreendi foi reescrever minimamente o driver das
> > > > placa de rede PCMCIA que uso (algumas Sanao baseadas no chipset
> > > > Prism).
> > > >
> > > > Um dos "efeitos colaterais" nao previstos do driver reescrito foi a
> > > > implementacao de um argumento de linha de comando do ifconfig que,
> > > > mensuravelmente, conseguia "derrubar" qualquer Access Point num
> > > > raio de, pelo menos, 20 metros indoor, com inumeras paredes de
> > > > alvenaria.
> > > >
> > > > Ha uma serie de funcionalidades para fins de testes de laboratorios
> > > > que sao suportadas no hardware e, certamente, nao sao utilizadas
> > > > pelos drivers "oficiais". Um hardware defeituoso, um driver mal
> feito,
> > > > ou um virus mais "esperto" podem, certamente, ativar alguma dessas
> > > > funcionalidades em areas ou momentos improprios.
> > > >
> > > > Analisadores de protocolo nao sao muito uteis para identificar,
> > > > tecnicamente,
> > > > o problema. Claro que ajudam a detectar equipamentos "rogue" e
> > > > posiciona-los, porem, para uma abordagem "cientifica", voce
> precisaria
> > > > de um analisador de espectro.
> > > >
> > > > <snip>
> > > >
> > > >
> > > > > Achei isto grave.... como pode um simples notebook derrubar a
> > conexões
> > > de
> > > > > todos os outros? Simplesmente desconectava o wireless. Acredito ser
> > um
> > > > > defeito no hardware do cartão wifi deste laptop que fazia alguma
> > coisa
> > > > > maluca como "sujar o spectro".  O fato que é realmente desconectava
> > > todos
> > > > > os
> > > > > outros e com o analisador de protocolo não pegava nada estranho e
> > > também
> > > > > não
> > > > > pegava nenhum outro AP em canais proximos (usando netstumbler).
> > > > >
> > > > > []'s
> > > >
> > > >
> > > > <snip>
> > > > --
> > > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > > >
> > > --
> > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > >
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
>
>
>
> --
> FSNETWORK CONSULTORIA
> hygor em bsd.com.br
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>



More information about the gter mailing list