Sniffers – Parte II


Introdução

No artigo passado, foi feita uma breve introdução sobre o que vem a ser sniffing , mostrando a teoria que há por trás e as potencialidades desta ferramenta (tanto para a administração de redes como para causar o caos nelas). Desta vez serei um pouco mais prático e falar sobre alguns programas de sniffing para GNU/Linux, aproveitar para simular um ataque e, claro, dar algumas dicas de proteção.

Programas

Como disse no artigo passado uma pesquisa rápida pela palavra “sniffer” mostra a abundância destas ferramentas tanto para GNU/Linux como também para outros sistemas. A tarefa de captura de pacotes, no mundo UNIX, é função da BPF (BSD Packet Filter), implementada principalmente nos BSD UNIX e da libpcap , nos demais. Esta biblioteca além de independente do sistema (leia: independente da forma com a qual o sistema operacional se relaciona com o dispositivo da rede) é compatível com a BPF.

Tanto ela quanto o tcpdump (um dos programas mais conhecidos para sniffing em GNU/Linux) são mantidos pelo “The Tcpdump Group” . Oa tcpdump é basicamente um programa que, como próprio nome diz, exibe na tela (ou direciona para um arquivo) o resultado daquilo que trafega em uma determinada interface. Sua saída é algo como isto (só por curiosidade isto acima é uma sessão de SSH, porta TCP 22):

22:38:48.827070 10.0.0.3.1023 > 10.0.0.1.22: F 3502340068:3502340068(0) ack 8033 57267 win 16060 <nop,nop,(452954 2426575 > (DF) [tos 0x10]
22:38:48.827203 10.0.0.1.22 > 10.0.0.3.1023: . ack 1 win 16060 >nop,nop,(2427891 452954 > (DF) [tos 0x10]
22:38:48.828988 10.0.0.1.22 > 10.0.0.3.1023: F 1:1(0) ack 1 win 16060 >nop,nop,(2427891 452954 > (DF) [tos 0x10]
22:38:48.829524 10.0.0.3.1023 > 10.0.0.1.22: . ack 2 win 16060 >nop,nop,(452954 2427891 > (DF) [tos 0x10]
22:38:51.253614 10.0.0.3.1022 > 10.0.0.1.22: S 3517906445:3517906445(0) win 16060 >mss 1460,sackOK,(453196[|tcp] > (DF)
22:38:51.254060 10.0.0.1.22 > 10.0.0.3.1022: S 928947415:928947415(0) ack351790 6446 win 16060 >mss 1460,sackOK,(2428133[|tcp] > (DF)


Para apenas ver o que está acontecendo na rede é ótimo mas muitas vezes apenas ver o que está trafegando na rede não é suficiente e a saída de um programa como o tcpdump pode parecer um pouco tediosa e chata após de um tempo de observação. Além de que tentar decodificar o que é um pedaço de arquivo, um trecho de uma mensagem fica bastante complicado.

Por esta razão que quando se procura por algo é melhor usar um analisador de pacotes. Estes programas (muitas vezes com função de sniffing embutidada) que interpretam aquilo que foi, ou está sendo, capturado e coloca da mais compreensível para humanos. Um analisador que eu gosto de usar é o ethereal , mas existem outros (alguns comerciais) basta procurar.

Apenas estes três programas já são mais do que suficientes para começar a fazer algumas experiências na sua rede. Sendo assim…

 

Ataque

Os protocolos mais vulneráveis a um ataque de sniffing são aqueles que transportam dados sem qualquer tipo de codificação, isto é, você digita “pato” e as letras “p”, “a”, “t” e “o” vão trafegar pela rede até seu destino final. Incluem-se nesta categoria Telnet, rlogin, HTTP, SNMP, SMTP, NNTP, POP, FTP, IMAP e além de serviços como talk, finger, whois, etc…

Sabendo disso pode-se, facilmente, simular um ataque de sniffing para exemplificar a vulnerabilidade de certas informações passando por eles. Assim montei uma rede de duas estações, ligadas por um cabo “cross-over” (um cabo de rede onde o Tx e o Rx de cada lado ligam-se, respectivamente, com o Rx e Tx do outro) para simplificar e para evitar a “poluição” gerada pelo tráfego de outros equipamentos.

Deixei o ethereal capturando os pacotes da rede na estação 10.0.0.1 . Enquanto que na 10.0.0.3 me comportei como um tranquilo usuário que, desconhecendo o que está acontecendo em sua rede, fez algo simples: baixar um arquivo via FTP de sua conta. Após ter baixado o arquivo, voltei até a máquina que deixei a estação com o sniffer e fui conferir os resultados.

A senha (“minhasenha”) que usei para me conectar no FTP foi devidamente interpretada pelo programa. E usando a opção “Follow TCP Stream” doEthereal pude recompor os pacotes TCP remontando a sessão:

220 artemis FTP server (Version wu-2.6.0(1) Fri Oct 22 00:38:20 CDT 1999) ready. 
USER giovanni 
331 Password required for giovanni. 
PASS minhasenha 
230 User giovanni logged in. 
SYST 
215 UNIX Type: L8 
(…) 
221-You have transferred 5556 bytes in 1 files. 
221-Total traffic for this session was 12566 bytes in 2 transfers. 
221-Thank you for using the FTP service on artemis 
221 Goodbye.

O resultado é que não só consegui obter a senha do usuário como pude recriar a sessão de FTP e saber de tudo o que ele fez, inclusive existem programas que fazem isto na rede! E a mesma coisa é válida para Telnet, HTTP, IRC, etc…

Proteção

Hardware

Evitar que uma rede local seja atacada assim é querer mexer naquilo que a faz funcionar, então o máximo que podemos fazer é complicar e dificultar um pouco. A primeira idéia que vem em mente é tentar usar adaptadores de rede que não entram em modo promíscuo . Alguns fabricantes até afirmam que possuem produtos assim mas a verdade é que de acordo com as recomendações do PC99 da Intel/Microsoft o modo promíscuo é uma característica obrigatória.

Assim, uma alternativa seria trocar a configuração da rede, substituíndo oshubs por switches . Mas porque? Ao contrário do hub , que é apenas uma emenda de barramento, o switch faz o papel de uma bridge , ou seja, ela faz uma ligação entre dois barramentos distintos, dividindo o tráfego da rede e deixando passar apenas o que realmente é para o outro lado.

Um frame que é enviado da máquina A para a máquina B será bloqueado, mas um frame de A (ou de B ) para C irá “atravessar a ponte” e chegar ao outro lado. Isto não impede o sniffing mas restringe o tráfego da rede para as partes onde ele é necessário. Com isto a quantidade de informação que pode ser adquiria pelo sniffing cai bastante.

 

Software

Mas também podem ser usadas soluções em software, duas que podem ser facilmente implementadas na rede são:

Além destas soluções outras podem ser implementadas (algumas não tão fáceis) como:

Conclusão:

Com isto encerramos este artigo ficando para a última parte algo que, em teoria, é impossível: detecção de sniffing. Até a próxima semana e para os que querem se divertir um pouco:

 

 

Autor: Giovanni Nunes – Fonte: Olinux.uol.com.br

Did you enjoy this post? Why not leave a comment below and continue the conversation, or subscribe to my feed and get articles like this delivered automatically to your feed reader.

Comments

Nenhum comentário ainda.

Deixe um comentário

(obrigatório)

(obrigatório)