O documento discute programas de sniffing para GNU/Linux como tcpdump e Ethereal, e como eles podem ser usados para capturar tráfego de rede e recuperar informações como senhas transmitidas sem criptografia. Também fornece dicas sobre como proteger redes usando switches em vez de hubs e protocolos criptografados como SSH.

1. http://olinux.uol.com.br/artigos/350/print_preview.html
Sniffers - Parte II
Por: Giovanni Nunes ( 10/07/2001 )
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
1 de 3 06-12-2009 12:42

2. http://olinux.uol.com.br/artigos/350/print_preview.html
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" do Ethereal 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 os hubs 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
2 de 3 06-12-2009 12:42

3. http://olinux.uol.com.br/artigos/350/print_preview.html
Mas também podem ser usadas soluções em software, duas que podem ser facilmente implementadas na
rede são:
Secure Shell (SSH): Foi inicialmente desenvolvido pela empresa finlandesa SSH e acabou se
transformando na ferramenta padrão para administração remota em máquinas UNIX, substituíndo
completamente o Telnet . Hoje já existem versões open-source e freeware tando do cliente quanto
no servidor. No SSH todo o tráfego é encriptado significando que mesmo alguém capture os pacotes
não conseguirá ver nada.
Virtual Private Network (VPN): É uma solução para fugir dos curiosos. Uma VPN é implementanda com
uma rede ponto-a-ponto virtual (túnel) ligando dois pontos através de uma rede pública (geralmente
a Internet). A vantagem da VPN é possuir encriptação nas pontas, isto é, tudo o que passa pela rede
pública é devidamente encriptado.
Além destas soluções outras podem ser implementadas (algumas não tão fáceis) como:
Kerberos
Secure Sockets Layer (SSL)
PGP
S/MIME
SMB/CIFS
Smart Cards
Stanford SRP (Secure Remote Password)
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:
Appwatch , procurem por sniffing
libpcap / tcpdump
Ethereal
Copyright (C) 1999-2000 Linux Solutions
3 de 3 06-12-2009 12:42