Usando um analisador de pacote para troubleshooting de rede – parte III

Olá a todos !

Percebi que não podia dividir esse artigo desse ponto em diante, então preferi publicar tudo de uma vez.

Faz mais sentido, portanto, vamos lá !

---

IV – Procurando algum tipo de tráfego na rede

---

Antes que você possa identificar um tráfego problemático, você deve primeiro entender como o que é um tráfego normal e quaç a “cara” dele. Vamos dar uma rápida olhada no tráfego ARP para ficar um pouquinho mais confortável com a exibição deste no nível de pacote.

As entranhas do ARP

A idéia básica por trás do ARP é para a máquina um broadcast de seu endereço IP e endereço MAC para todos os clientes dentro do seu domínio de broadcast a fim de encontrar o endereço IP associado com um endereço MAC específico para o qual ele deseja transmitir. Digamos que a máquina A queira conversar com a máquina B, mas máquina A não sabe o endereço MAC da máquina B, mas sabe o endereço IP. Então, ele basicamente se parece com isso :

Computador A – “Oi a todos ! Meu endereço IP é xx.xx.xx.xx, e o meu endereço MAC é XX:XX:XX:XX:XX:XX. Eu preciso enviar uma informação para alguém com o endereço IP xx.xx.xx.yy, porém eu não sei qual é o seu endereço MAC. Quem tiver este endereço IP, por favor, responda com seu endereço MAC ?”

Todas as máquinas no segmento, no domínio de broadcast, irão receber esse broadcast ARP, e somente uma máquina irá responder: aquela que tiver o endereço IP requisitado pelo computador A. Com esta informação na mão, a troca de dados se inicia entre as máquinas.

Computador B – “Oi computador A ! Sou quem você procura. Tenho o endereço IP xx.xx.xx.yy. E meu endereço MAC é XX:XX:XX:XX:XX:YY.”

Bem… já conhecemos o processo do protocolo ARP a fundo. Apenas fiz aqui um refresh da informação para que todos fiquem espertos. 😉

 

ARP no nível de pacote

---

Entendendo o conceito básico do ARP, podemos dar uma olhada em alguns pacotes para ver como ele atualmente funciona.

Agora, vamos passo-a-passo por todo o processo ARP, do início ao fim. Ok? Neste cenário o computador A precisa se comunicar com o computador B.

O Wireshark permite que você salve sua captura, gerando assim arquivos com a extensão .pcap. Você pode baixar o arquivo desta captura ARP aqui. Veja. Optei por usar uma captura que vocês possam carregar no aplicativo, para que você possa acompanhar o passo-a-passo da análise do tráfego. E mais. Observem que o intuito aqui não é esgotar o assunto que é extenso. Aqui é somente o ponta-a-pé inicial para que você mesmo trilhe seu caminho no uso da ferramenta.

Na janela detalhes do pacote do primeiro pacote do arquivo de captura é direto. O computador 192.168.0.114 precisa se comunicar com o computador 192.168.0.1, porém ele não conhece o endereço MAC do destino (Who has 192.168.0.1? Tell 192.168.0.114). Observe que o endereço MAC alvo aqui é 00:00:00:00:00:00. E nesse caso, ele envia o pacote com o endereço MAC ff:ff:ff:ff:ff:ff, fazendo um broadcast deste pacote por todo o segmento de rede. Este é o pacote básico ARP Request, conforme visto no campo Opcode na sinalizado abaixo.

O segundo pacote é o nosso REPLY vindo da máquina 192.168.0.1. Este dispositivo recebeu o ARP Request no primeiro passo, e gerou este reply endereçado a 192.168.0.114. Observe que este reply contem a informação que a máquina 192.168.0.114 precisa para se comunicar efetivamente com a máquina 192.168.0.1, que é o endereço MAC 00:13:46:0b:22:ba. O endereço MAC desta última está neste pacote. Vc pode dizer imediatamente que este é um ARP reply só olhando o campo Opcode.

Resumindo e importante saber :

Quando o campo Opcode tem 0x0001 é request.

Quando o campo Opcode tem 0x0002 é reply.

Uma vez que o dispositivo 192.168.0.114 recebeu o reply, este então pode pegar o endereço MAC de 192.168.0.1 e colocá-lo no cache ARP para uso futuro. Com esta nova informação, o ARP pode com sucesso traduzir a camada 2 e a camada 3, de modo que a comunicação possa se mover pelo meio físico.

 

V – Troubleshooting de um problema real na sua rede

---

Chegou a hora “H”. Vamos mergulhar fundo na comunicação feita na sua rede, dando uma olhada em um cenário real com um problema real e compreendê-lo no nível de pacote com a ajuda do Whireshark.

Neste cenário, uma empresa tem um servidor FTP que é utilizado para manter todos os seus releases de software. Recentemente, um técnico responsável pela manutenção recebeu diversos relatos dos desenvolvedores da empresa reportando que na ocasião quando trabalhavam até mais tarde na empresa, a performance do upload/download fica bastante degradada. Neste servidor FTP está rodando uma aplicação simples de FTP que tem features de logging, fornecendo toda informação necessária. ok. Este é  o  cenário perfeito para o uso do sniffer de pacote.

Um arquivo de captura pode ser melhor obtido ao usar a técnica de espelhamento de porta para obter do fio a captura apropriada do dado. Mas algo melhor pode ser feito, se você instalar o Wireshark diretamente na máquina em questão, porém se performance é um problema, então isso gera um risco, e poderia fazer com que pacotes fossem dropados, reduzindo assim a validade de nossa captura. Aqui também usaremos o arquivo .pcap. Para isso, faça download da captura de tráfego FTP aqui.  Carregue o arquivo e continue a ler.

Quando você abriu seu arquivo de captura, viu que muita coisa está acontecendo dentro de um curto espaço de tempo. Observe a coluna “time” dentro da janela lista de pacote onde é exibido os primeiros 200 pacotes cruzando o fio em menos de 1 segundo.

Este número não significa muito, visto que não podemos usar isso também eficazmente para ver a taxa de dados fluindo através do fio, mas não há outra maneira de fazer isso. Selecione Statistics do menu principal e então escolha Summary. Irá abrir uma tela de resumo que dará um overview de algumas estatísticas para todo o processo de captura.

Se você olhar o último pedaço de dado exibido na tela, você verá que a taxa média Mbit/segundo é de 0.233. Não é MUITO dado capturado, porém é significante o bastante para você se preocupar.

Olhando novamente a janela lista de pacotes, existe muito dado para ser compreendido e digerido; aproximadamente 20.000 pacotes. Quando procurando neste pacotes, é uma boa idéia iniciar como nós podemos limitar o campo de pesquisa. E o melhor meio de fazer isto é usando a janela Conversations.

Uma conversa na rede, é exatamente como uma conversa entre duas pessoas (opaaaaaa … com duas mulheres precisamos de uma largura de banda maior… :))  ), descreve a comunicação que acontece entre 2 hosts (também conhecido como pontos-finais). Vc pode acessar janela de Conversations ao selecionar Statistics no topo da tela e escolher Conversations.  Fazendo isto, você irá exibir uma lista de todas as conversas dentro da captura com alguma informação sobre cada conversa.

Nesta captura entretanto, somente uma conversação é listada. Isto significa que todos os 20.000 pacotes exibidos estão sendo transmitidos entre o servidor FTP e o mesmo host.

Assim, verificamos que somos incapazes de delimitar nossa pesquisa usando a janela Conversations. “O que fazer ?”, você pensa. Calma. Vamos para o próximo passo que é utilizar um filtro para efetuar essa tarefa. Sabemos que este é um servidor FTP, e olhando o painel lista de pacotes, temos uma mistura de pacotes de tráfego TCP e FTP. Uma boa estratégia é isolar o tráfego FTP. E isto pode ser feito ao se criar um filtro de exibição.

Um filtro de exibição é um filtro que diz ao Wireshark para somente exibir pacotes que batem com certos critérios. Podemos criar um filtro ao digitar o critério que queremos na caixa Filter que fica imediatamente acima do painel lista de pacotes. Se você digitar “ftp” (por favor… sem as aspas) dentro desta caixa e der enter, e somente o tráfego FTP será exibido no painel lista de pacotes.

Agora, o painel detalhes do pacote pode ser verificado para se ter uma idéia do que cada pacote FTP está fazendo. Para fazer isto, selecione um pacote no painel lista de pacote e então expanda a seção FTP no painel lista de pacotes. Se você fizer isto para o primeiro pacote FTP, você verá uma resposta sendo enviada do servidor (10.121.70.151) para o cliente (10.234.125.254), declarando que uma tentativa de login falhou :

Response arg : Login incorrect.

Se você continuar com esta investigação, olhando os detalhes de cada pacote FTP, você começará a compreender e ver a tendência do seu tráfego. Bem, a captura inteira consiste de um host remoto tentando e falhando ao logar no servidor FTP. E não somente você pode ver estas tentativas de login, e visto que todo tráfego está desencriptado, você pode também ver as senhas FTP que foram sendo tentadas ao logar.

Agora, olhe os pacotes 11, 17, 21 e 47, e você poderá ver que o cliente remoto tentou o login com as senhas merlin, mercury, mets e mgr, respectivamente. E não somente isso, mas se você olhar na coluna “time“, todas estas tentativas de login aconteceram em 2 décimos de segundo. Muito rápido esse cara, não é ?!? O que você acha ? Será que é ele mesmo que está digitando essas senhas?!?! Eu tenho certeza que não.

Apenas para verificar mais um pouquinho sobre isso, podemos usar um filtro mais avançado para exibir todas as tentativas de login para este servidor FTP. Usando o seguiten filtro de exibição…

ftp.request.comand == PASS

… e ai você irá exibir todas as senhas que o cliente remoto usou para tentar logar no seu servidor FTP.

Hum…. o que temos aqui ?!? Tentativas rápidas e múltiplas de login usando senhas alfabéticas sequenciais?!? SIM !

É um sinal claro de que alguém está tentando violar a segurança do seu servidor FTP usando um ataque de força bruta !

Ok. Tivemos sucesso ao usar o Wireshark não somente para rastrear que o podia estar causando a degradação de performance do seu servidor FTP durante o horário de maior movimento, além de também identificar um potencial intruso.

É isso. Você está pronto para “ouvir” e capturar seu tráfego de rede.

 

Conclusão

---

Gosto de frequentemente comparar o trabalho de um Analista de Rede, ao trabalho de um médico com seu paciente. Apesar do médico ser um especialista, cardiologista, neurologista ou ortopedista, todos, sem exceção, iniciam com medições básicas para ver seu bem estar geral. Onde um médico pode fazer uma cultura sanguínea, um Analista de Rede visualizará a hierarquia de um protocolo; onde um médico tem histórico completo médico, uma anammese para obter um padrão de comparação da saúde de seus pacientes, um Analista de Rede irá executar algumas capturas de pacotes para obter um padrão de comparação da saúde de sua rede.

A idéia aqui é que você tem de saber o que fazer quando certos sintomas são observados na sua rede antes de focar no problema específico, que é a causa do sintoma. Visualizar um problema na rede não é tão fácil como capturar alguns pacotes e olhar para a palavra “ERROR” bem grande na sua frente. Vc tem que saber que “coisas” são essas e quando elas parecem estar funcionando corretamente, para que em contrapartida você possa encontrar as sutilezas que fazem a diferença entre uma rede com a saúde perfeita e outra que se arrasta lentamente e se nada for feito, chega a um estado terminal. O único modo de fazer isto efetivamente é ser capaz de interceptar os pacotes que estão fluindo através do cabo.

Este artigo foi idealizado para a você dar apenas uma direção do que se pode fazer com um sniffer de pacote e quão essencial ele é para a análise dos pacotes fluindo pela sua rede.

Existem muitos sites na Internet sobre o assunto, mas recomendo que você aprenda mais sobre análise e sniffing nos “caras” oficiais:

Site oficial do Wireshark, onde você encontra os downloads e os links de suporte.

OpenPacket é um site que fornece um repositório centralizado de traces de tráfego de rede para pesquisadores, analistas e outros membros da comunidade de segurança digital. Aqui você cria um login e senha para baixar os arquivos .pcap do Wireshark  que podem estar em 3 categorias : Normal, Suspicious e Malicious.

Este é o site de Laura Chappell´s. Existe muito material free que você pode utilizar para seu estudo.

Este é o site de Richard Bejtlich. Ótimo site sobre Segurança de rede.

Fonte: Chris Sanders

Bem, poderíamos ficar aqui o dia todo falando sobre sniffers, captura, e etc, e conversando sobre como, onde, e o que capturar na sua rede quando ela está dando sinais de decriptude. (rs). Mas aqui termina a série. Agora cabe a vocês explorarem o Wireshark e tirar o máximo que puderem dele.

É importante salientar que o conhecimento sobre os campos do frame (L2), pacote (L3), segmento (L4), e com especial foco sobre a camada 4, Transporte, TCP e UDP, será essencial para que você saiba o que está capturando. E para isso, vem ai uma nova série de artigos falando sobre os Protocolos TCP e UDP. Aguardem.

É  isso, meus amigos. Espero que seja útil a todos.

Obrigada por tudo, e até o próximo artigo. 🙂

Sds,

Márcia Guimarães