Oficina
WireShark - o devorador de pacotes
|
Seg 7 Mai 2007 21:20 |
- Detalhes
- Categoria: Ferramentas de Rede
- Atualização: Quinta, 21 Janeiro 2010 22:07
- Autor: vovó Vicki
- Acessos: 50645
Você já tentou rastrear pacotes numa rede? Não!!?? Então está na hora de começar a se divertir olhando o caminhão de pacotes que transitam entre suas conexões (seu computador com a Internet, com o cliente de email, ftp, etc e tal) e a entender como as conexões são estabelecidas e mantidas.
Introdução
Se é que existe uma ferramenta que fez história na arte do "packet sniffing", esta é o Ethereal. Foi usada durante anos por especialistas em redes... e também por hackers. Acontece que os mesmos desenvolvedores do Ethereal resolveram dar um passo à frente, melhoraram o código e trocaram o nome do soft para WireShark - tubarão dos fios. Este analisador de protocolos de rede é uma excelente ferramenta para inspecionar redes, desenvolver protocolos e, de quebra, pode ser usada para fins educacionais. Foi escrita por profissionais do ramo e é um exemplo do poder do software de código aberto. Roda em Windows, Linux, UNIX e outras plataformas... precisa dizer mais?
Você encontra o WireShark para Windows na seção de downloads da Aldeia em Informática/Ferramentas de Rede ou no site do projeto indicado nas Fontes para o software no final deste texto.
Botando a mão na massa
Faça o download e instale o programa. Quando for perguntado se o WinPcap deve ser instalado, responda que sim (se ele não estiver instalado). Como o WireShark precisa desta biblioteca de captura de pacotes para funcionar, ela está incluída no instalador.
Em algumas instalações que fiz, na hora de instalar o WinPcap recebi uma mensagem de erro sobre o NetMon que dizia "An error occurred while installing the Microsoft Network Monitor Driver (NetMon) (0x800F0203)...". Não me deixei impressionar e continuei a instalação e tudo funcionou bem.
Numa determinada instalação ignorei o mesmo erro, só que, quando tentei rodar o Wireshark ele se recusava a funcionar indicando que o arquivo npptools.dll não podia ser encontrado. Neste caso específico descobri que a instalação do Windows XP havia "subtraído" esta biblioteca dinâmica. Procurei no Google onde poderia baixá-la e a coloquei no diretório /windows/system32/ e o problema foi resolvido. Espero que estas duas informações ajudem a quem está começando.
Dito isto, bote o Wireshark para rodar e vamos lá. A telinha deve mostrar algo como o mostrado na Fig.1:
A primeira coisa que precisamos indicar é a interface de rede que deve ser rastreada. Clique em [Capture/Interfaces] para ativar a janela de escolha mostrada na Fig.2:
Escolha uma interface e clique no botão [Start] - se a interface estiver ativa, o rastreamento começa imediatamente e a janela principal do WireShark passa a mostrar uma porção de pacotes.
Para ilustrar, chamei o Google no browser e obtive os pacotes mostrados na Fig.3:
Para interromper a captura de pacotes clique no quarto botão da barra de ferramentas ou no item de menu [Capture / Stop]. Veja que diversos tipos de pacotes foram capturados - esta versão do WireShark reconhece 836 tipos de pacotes (protocolos) diferentes.
O primeiro deles (pacote 1) foi gerado pela minha máquina para enviar em broadcast uma mensagem ARP (Address Resolution Protocol - Protocolo de Resolução de Endereço). É que o browser está pedindo um domínio (no caso, google.com) que está fora da rede local, ou seja, minha máquina precisa fazer uma conexão com um servidor de páginas localizado numa outra rede e precisa de "licença" para sair. Esta licença só pode ser dada pelo roteador da minha rede, cujo endereço IP é 198.168.1.2. Para poder falar com esta máquina, a placa Ethernet do meu computador precisa do número (MAC) da placa Ethernet do roteador. Como ela não tem esta informação, ela solta um "berro" em broadcast. Um broadcast funciona mais ou menos assim: minha máquina dá um grito do tipo "Quem tem o 192.168.1.2? Responda para 192.168.1.1" que pode ser ouvido em toda a rede. Apesar de todas ouvirem, apenas a máquina com o endereço perguntado vai responder - e vai responder diretamente para a minha máquina.
0.000194 segundos depois, a resposta chegou no pacote número 2. Se a pergunta saiu em forma de ARP, a resposta também vem no mesmo protocolo informando que a máquina solicitada tem o endereço MAC 00:40:26:a7:67:49. Agora as duas placas Ethernet têm como se comunicar e nós podemos dar uma voltinha lá fora.
Acontece que o browser recebeu o nome de um domínio (google.com) e não tem a mínima idéia do endereço IP deste domínio, ou seja, minha máquina precisa de um serviço de tradução que transforme nomes de domínio em endereços IP. Existem máquinas especializadas em fazer estas traduções - são os chamados servidores de nomes ou DNS. Meu sistema está configurado para procurar o servidor de nomes no endereço IP 200.195.157.66, por isto envia um pacote DNS (pacote 3) solicitando a tradução desejada. O servidor de nomes aciona um outro servidor de nomes, o pt-br.start2.mozilla.com, que responde logo em seguida.
O pacote 4 traz a tradução solicitada: google.com tem o endereço IP 72.14.209.99. Finalmente minha máquina pode fazer contato com uma das máquinas servidoras de páginas da gigante Google. É o que ela faz ao enviar o pacote 5.
Vamos dar uma olhada mais de perto neste pacote só para ir se acostumando com a sequência de acontecimentos. Clicando no pacote 5, os painéis de resultado mostram o seguinte (Fig.4):
O painel superior contém a lista dos pacotes capturados, onde o pacote 5 está destacado. Os outros dois painéis contém informações sobre este pacote.
No painel do centro aparecem quatro barras com um botão [+] no lado esquerdo. Clicando neste botão, as informações sob este título são mostradas. Para esclarecer um pouco o que tudo isto quer dizer, é bom dar uma recordada como um pacote TCP é fabricado.
O protocolo TCP (Transmission Control Protocol - Protocolo de Controle de Transmissão) é acionado pelo aplicativo que, no nosso exemplo, é o browser. O browser fornece algumas informações para que o TCP possa montar seu pacote. Este primeiro pacote é passado para o protocolo IP (Internet Protocol) - responsável pelo roteamento, isto é, precisa definir a origem e o destino do pacote para que ele possa ser direcionado corretamente. O IP adiciona as informações que são da sua competência e "embrulha" o pacote recebido junto com o que ele produziu. Resultado: o pacote fica maior e já pode ser chamado de pacotão. O IP transfere este novo embrulho para a placa Ethernet que, como toda boa placa de rede, faz um novo embrulho adicionando seu endereço MAC e o MAC do destino - o pacotão vira um pacotaço, mais conhecido como frame Ethernet.
Bem, chegou a hora de conferir se a vó aqui não está falando bobagem :blush: Clique no título Transmission Control Protocol e observe no painel inferior, onde o pacote é mostrado na sua forma hexadecimal, o final do pacote em destaque: esta é a parte criada pelo TCP. Clique no título Internet Protocol e observe no painel inferior que o miolo do pacote é destacada. Finalmente, clique no título Ethernet II para ver o início do pacote destacado. Agora, adivinhe o que? Se clicarmos no título Frame, o pacotaço será destacado.
Para falar a verdade, esta história de pacote, pacotão e pacotaço é uma invenção minha só para facilitar o entendimento de como um pacote é criado. Quando falamos em pacotes, referimo-nos sempre ao produto final que transita pela Internet (o pacotaço).
Mas vamos continuar com a dissecação do pacote seguindo o roteiro comentado acima. A primeira conversa é entre o aplicativo e o TCP. O browser "explica" que a porta TCP de origem é a 3172 e que a porta TCP do destino deve ser a 80 (reservada para o HTTP). A porta de origem vai servir para direcionar a resposta e a porta do destino vai servir de informação para que o TCP da outra ponta saiba o que fazer. Se o botão [+] do título Transmission Control Protocol for clicado, vamos obter o seguinte (Fig.5):
Como este pacote vai ser enviado com um pedido de sincronização, é quase que óbvio que a flag SYN precisa estar ligada. Clique na linha ".... ..1. = Syn: set" para identificar onde este bit se encontra dentro do pacote. Além das portas e do bit SYN, o resto pode esperar um pouco. Vamos dar uma olhada no que o IP aprontou.
Agora é a vez de dar uma olhada no que o IP produziu. Observe a Fig.6 onde, ao invés de destacar a porção do pacote que lhe compete, cliquei numa outra flag: a que não permite fragmentações.
Como foi dito anteriormente, o IP é o responsável pela rota que o pacote deve tomar, ou seja, precisa indicar endereços IP de origem e de destino. Se você clicar em Source e Destination, a porção do pacote que contém estas informações será destacada no painel inferior e você verá os endereços na sua forma hexadecimal.
Bem, agora só falta ver o que a placa Ethernet aprontou. Na verdade, não é nada de excepcional porque os MACs da origem e do destino já tinham caído na boca do povo 
Usando estas informações, a plaquinha embrulha tudo e joga o pacote na rede... agora só resta esperar que o pacote chegue ao destino e que a minha máquina receba uma resposta.
Como o protocolo TCP faz um "aperto de mão" em três etapas, então também é aconselhável dar uma repassada neste processo. A primeira cutucada é enviar um sinal SYN, aí se espera uma resposta SYN-ACK (a máquina contactada envia um "ACKnowledgment" - um palavrão em inglês que quer dizer conhecimento). Como somos muito educados, também respondemos com um ACK para dizer que recebemos a resposta. Final da história: os dois pacotes que seguem o que acabamos de analisar devem conter estas informações e, como você já sabe onde procurar, é só pregar o chinelo.
Recado da vó Vicki 
Caso você ainda esteja usando o Windows 98, ao invés do WireShark use o Ethereal versão 0.10.14. Ele entende "só" 736 protocolos, tem a mesma aparência e funciona tão bem quanto o seu irmão mais moderninho.
Bom divertimento e sucesso!
Referências para o software
- Site oficial do WireShark
- Site oficial do WinPcap
- Ethereal 0.10.4 - Versões mais antigas do WinShark.