Muitas pessoas utilizam ferramentas que operam de forma passiva para capturar pacotes da rede. Este tipo de “sondagem� é extremamente interessante porque nenhum pacote é inserido na rede alvo. Ou seja, não ocorre troca de informações entre o “espião� e a rede. Isto torna o indivíduo que se utiliza de tais métodos praticamente indetectável.

Sondar uma rede passivamente é fácil. Basta ter uma NIC (Network Interface Card – placa de rede) capaz de operar no modo promíscuo monitor ou RFMON (Radio Frequency Monitor) e um programa. A interface quando em modo promíscuo escuta toda a rede – ou – recebe todos os pacotes que nela trafegam. Já o RFMON é caracterizado por entender pacotes específicos de redes sem fio (por exemplo: difusão do nome da rede – ESSID).

Por vários motivos, nem todas as placas conseguem trabalhar no modo de monitoramento. O Sistema Operacional, por exemplo, influencia diretamente no sucesso ou não deste procedimento. A placa ipw2200, até o momento, não consegue operar no modo monitor no Windows (XP). Mas no Linux é extremamente fácil colocá-la para trabalhar neste modo. Alias, Linux é o SO mais indicado aos que desejam se aventurar no mundo da espionagem passiva, pois possui uma quantidade considerável de drivers com capacidade para RFMON.

Abaixo algumas placas que operam em RFMON – classificadas por tipo de sistema:

Linux: Atmel_USB, ACX100, ADMTek, Atheros, Cisco, Prism2, Orinoco, WSP100, Drone, wtapfile, pcapfile, wrt54g, ipw2100, rt2400, rt2500, rt8180, ipw2200, ipw2915, ipw3945 e Broadcom 43xx;

OpenBSD: Prism2 (wi), Atheros (ath), Intel 2200/2225/2915 (iwi), Intel 2100 (ipw), Ralink (ral and ural), Realtek RTL8180L (rtw), WSP100, Drone, wtapfile e pcapfile;

FreeBSD: Atheros, Prism2, WSP100, Drone, wtapfile e pcapfile;

MacOSX: Airport, WSP100, Drone e wtapfile;

Win32: WSP100, Drone, wtapfile e pcapfile. Desconhecemos drivers públicos de RFMON para Win32.

Observação: o suporte por tipo de sistema está em constante alteração. Ainda restam esperanças se um chipset específico não está na lista acima. É só procurar em artigos mais recentes.

A VsF possui um notebook Centrino com adaptador Mini-PCI Pro/Wireless 2200 (ipw2200). Ver:

A interface de captura desta placa é ethX. Para colocá-la no modo promíscuo monitor basta utilizar o seguinte comando:

root@vivasemfio:/# ifconfig eth0 promisc

root@vivasemfio:/# ifconfig eth0
eth0 Encapsulamento do Link: Não Especificado Endereço de HW 00-**-35-**-D5-AA-**-CA-00-00-00-00-00-00-00-00
endereço inet6: fe80::20e:35ff:fe60:d5aa/64 Escopo:Link
UP BROADCASTPROMISC MULTICAST MTU:1500 Métrica:1
RX packets:7924 errors:0 dropped:0 overruns:0 frame:0
TX packets:901 errors:0 dropped:0 overruns:0 carrier:1
colisões:0 txqueuelen:1000
RX bytes:25401 (24.8 KiB) TX bytes:0 (0.0 b)
IRQ:11 Endereço de E/S:0×8000 Memória:cffff000-cfffffff

Alguns programas, como o Kismet, ao serem ativados colocam a placa em modo de monitoramento automaticamente.

Muitas pessoas reclamam da instabilidade duma placa quando esta opera em RFMON. Nesses casos, é comum existir uma relação do problema com o DHCP habilitado. Funciona assim: o modo monitor entra em ação antes da obtenção de endereço por DHCP. Após algum tempo (cerca de 1 minuto) o tempo de espera do DHCP termina e a interface é desligada. Ou, recebe-se um endereço por DHCP. Mas será incapaz de renová-lo. Ao ocorrer uma tentativa de renovação, desliga-se a interface. Para evitar tais problemas, basta desabilitar o DHCP.

É isso pessoal…

Abraços !!!

Algumas distribuições do linux possuem utilitários gráficos para auxiliar o usuário quando este for se conectar a um ponto de acesso. Isto é ótimo, pois tudo se torna rápido e fácil. Na imagem abaixo temos exemplo:

Este é um utilitário que encontramos no Kurumin. Nele, além da possibilidade de verificar os APs disponíveis e configurar uma associação, temos o Ndiswrapper. Basicamente, o Ndiswrapper permite ativar placas wireless no linux utilizando drivers do Windows. Porém, está fora no escopo deste artigo tratar sobre o Ndis. Falaremos aqui sobre associações. E mais: nem sempre dispomos de um utilitário gráfico para facilitar a nossa vida. Algumas vezes é preciso levantar uma placa wireless e conectá-la num ponto por linhas de comando. Ou, como dizem alguns fãs do pingüim, “no braçoâ€?. Então vamos lá…

Obs: a placa wireless será vista pelo sistema (eth0, eth1, wlan0, etc) conforme o driver utilizado. “wlan0� é a forma mais comum, porém em nossos testes o sistema adotou “eth1�.

Antes de qualquer ação, vamos detectar os APs disponíveis na região. Para isso basta utilizar o seguinte comando:

root@vivasemfio:/# iwlist scan
lo Interface doesn’t support scanning.

eth0 Interface doesn’t support scanning.

eth1 Scan completed :
Cell 01 - Address: XX:XX:XX:XX:XX:XX
ESSID:”TUCANO”
Protocol:IEEE 802.11bg
Mode:Master
Channel:5
Encryption key:on
Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 6 Mb/s; 9 Mb/s
11 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s
48 Mb/s; 54 Mb/s
Quality=100/100 Signal level=-15 dBm
Extra: Last beacon: 108ms ago

A varredura capta diversas informações interessantes dos pontos ativos. Entre elas MAC address, ESSID, canal e criptografia. Acima encontramos o AP da VsF cujo ESSID é TUCANO e com encriptação via WEP ativa (Encryption key:on).

Para conseguir associação com este AP, a primeira informação que deve ser fornecida é o ESSID. Assim:

root@vivasemfio:/# iwconfig eth1 essid TUCANO

Feito isso definiremos o canal:

root@vivasemfio:/# iwconfig eth1 channel 5

Os canais, em teoria, podem variar de 0 a 16. Porém, apenas 14 deles, de 1 a 14 são licenciados pelo FCC e a lista diminui mais um pouco de acordo com o país envolvido. Nos EUA é permitido o uso dos canais de 1 a 11, na Europa de 1 a 13 e no Japão de 1 a 14. Enquanto escrevemos este artigo, no Brasil, esta situação ainda é confusa.

De posse da chave WEP, utilizaremos o seguinte comando:

root@vivasemfio:/# iwconfig eth1 key restricted 3e699b884db0e409ddd099a4ec

Por fim, basta definir o IP da estação e o IP do ponto de acesso. Assim:

root@vivasemfio:/# ifconfig eth1 192.168.1.89 netmask 255.255.255.0
root@vivasemfio:/# route add default gw 192.168.1.1

Prontinho. É só testar:

root@vivasemfio:/# ping www.uol.com.br
PING www.uol.com.br (200.221.2.45): 56 data bytes
64 bytes from 200.221.2.45: icmp_seq=0 ttl=57 time=37.0 ms
64 bytes from 200.221.2.45: icmp_seq=1 ttl=57 time=37.1 ms
64 bytes from 200.221.2.45: icmp_seq=2 ttl=57 time=40.0 ms
64 bytes from 200.221.2.45: icmp_seq=3 ttl=57 time=36.2 ms

— www.uol.com.br ping statistics —
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 36.2/37.5/40.0 ms

Tudo funcionando! Pingüim conectado!

Caso o DHCP estiver habilitado no AP, podemos ignorar os seguintes passos:

root@vivasemfio:/# ifconfig eth1 192.168.1.89 netmask 255.255.255.0
root@vivasemfio:/# route add default gw 192.168.1.1

É só utilizar o comando “pump –i X�. Exemplo:

root@vivasemfio:/# iwconfig eth1 essid TUCANO
root@vivasemfio:/# iwconfig eth1 channel 5
root@vivasemfio:/# iwconfig eth1 key restricted 3e699b884db0e409ddd099a4ec
root@vivasemfio:/# pump -i eth1
root@vivasemfio:/# ping www.uol.com.br
PING www.uol.com.br (200.221.2.45): 56 data bytes
64 bytes from 200.221.2.45: icmp_seq=0 ttl=57 time=37.0 ms
64 bytes from 200.221.2.45: icmp_seq=1 ttl=57 time=37.1 ms
64 bytes from 200.221.2.45: icmp_seq=2 ttl=57 time=40.0 ms
64 bytes from 200.221.2.45: icmp_seq=3 ttl=57 time=36.2 ms

— www.uol.com.br ping statistics —
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 36.2/37.5/40.0 ms

Obs: o comando “pump –i X� só pode ser utilizado em algumas distribuições, como a Knoppix. Nas outras, cujo suporte não existe, deve-se usar o comando “dhcpcd X�.

É isso pessoal…

Abraços !!!