Linux e CIA: iMasters - Como a análise de tráfego salvou meu emprego - Parte 01

terça-feira, julho 21, 2009

iMasters - Como a análise de tráfego salvou meu emprego - Parte 01 - Linux

Segunda-feira, 13/07/2009 - 09:30 - Por Júlio Henrique Conceição
Seções relacionadas:
Como a análise de tráfego salvou meu emprego - Parte 01
Algumas vezes, como consultor na área de redes, me deparei com situações nas quais, mesmo com todas as configurações corretas, problemas estranhos aconteciam. Então, esgotadas as demais tentativas de diagnóstico, decidia realizar a análise do tráfego na rede. E estas análises definitivamente me ajudaram a resolver os problemas.
O que é análise de tráfego?
Chamada por alguns de análise de pacotes, é o processo de interceptar e examinar as informações que trafegam em um segmento de rede, visando a identificação de problemas; assim como a maioria das ferramentas, também pode ser usada para coletar informações para atividades de hacking (coletar senhas não criptografadas, mensagens instantâneas, etc).
Quais as ferramentas utilizadas?
As ferramentas utilizadas para análise de tráfego são também chamadas de sniffers.
Administradores Linux conhecem muito bem o tcpdump, um poderoso sniffer que geralmente se encontra instalado na maioria das distribuições.
O tcpdump captura o tráfego que passa através do meio físico onde ele está conectado, com as opções de mostrá-lo na tela (o que não é muito prático, principalmente se houver alto tráfego na rede), ou armazená-lo em um arquivo para análise posterior (opção mais utilizada).
Existe, também, o wireshark (antigo ethereal) que, além de possuir as mesmas funcionalidades do tcpdump, conta com interface gráfica e algumas ferramentas para facilitar a análise.
Geralmente, utilizamos o tcpdump para coletar o tráfego em um arquivo, e o wireshark para analisá-lo posteriormente e, preferencialmente, em uma máquina diferente daquela da qual o tráfego foi coletado. Quando existem problemas no acesso à Internet, por exemplo, realizamos a coleta no gateway da rede (ou em uma máquina "em paralelo" com este, utilizando espelhamento de portas no switch), e a análise na estação de gerenciamento da rede.
Problema
Certa vez, fui chamado para verificar um problema de lentidão no acesso à Internet. A equipe de helpdesk da empresa informou que o primeiro acesso após ligar a estação levava mais de um minuto para ocorrer; porém, os demais acessos ocorriam sem problemas. Neste ambiente, quando a estação tentava o primeiro acesso, sua conexão era redirecionada para que fosse realizada uma autenticação e, sendo fornecido usuário e senha válidos, a navegação era liberada. Era justamente este tela de autenticação que demorava a ser exibida.
O trabalho
A primeira atitude foi implementar o MRTG para gerar gráficos de utilização do link; estes revelaram que a utilização poucas vezes atingia o limite contratado de banda.
Depois, verifiquei a autenticação, pois era esta que apresentava lentidão mas, uma vez autenticado, o usuário passava a acessar a Internet em velocidade satisfatória. Porém, também não foi encontrado nenhum problema; e, quando executávamos logout do servidor de autenticação (sem reiniciar a máquina) e tentávamos um novo acesso (utilizamos como teste a página do UOL), a tela de autenticação era exibida rapidamente.
Decidi, então, acompanhar o tráfego gerado da estação rumo à Internet, rodando o tcpdump em uma máquina em paralelo com o gateway (firewall) da rede, que não era uma máquina linux.
Coleta e análise
Coloquei o tcpdump para coletar e armazenar o tráfego da estação que estava utilizando, através do comando:
 tcpdump -i eth0 -n -s 65500 host 192.168.7.90 -w captura1.pcap
Onde:
-i: indica a interface de rede de onde o tcpdump irá capturar o tráfego;
-n: indica que o tcpdump não deve tentar resolver os nomes dos hosts;
-s: indica a quantidade em bytes que será capturada em cada pacote;
host: o endereço IP (ou o nome) da estação que queremos monitorar; a omissão deste parâmetro capturaria o tráfego de todas as estações e, dependendo da quantidade de tráfego na rede, deixaria o arquivo de log muito grande em poucos minutos;
-w : indica o arquivo que irá armazenar os dados coletados.
Na captura de tela do wireshark, vemos o dump do primeiro pacote (número 47) de requisição (com a flag SYN habilitada) com destino ao endereço IP da home do UOL (200.98.249.120).
Vemos, também, que esta requisição aconteceu às 18:14:28.
Após o envio do primeiro pacote, ocorreram diversas requisições para o endereço osce80-en.url.trendmicro.com, cujo endereço IP é 72.246.216.41, utilizando em cada acesso uma URL diferente. Abaixo, um dump do pacote número 53, das 18:14:29, um segundo após a requisição à página do UOL:
Finalmente, a autenticação ocorre às 18:15:17, 49 segundos após a requisição inicial, conforme dump do pacote número 105:
O mais intrigante neste caso eram as requisições para um servidor da Trendmicro.
Pude observar que as estações utilizavam o antivírus Trendmicro Officescan versão 8.0.
Desativamos temporariamente o antivírus e, com a estação recém iniciada, tentamos um novo acesso: a exibição da tela de autenticação foi praticamente instantânea. Porém, desabilitar o antivírus não era uma alternativa válida, por motivos óbvios.
Após pesquisar um pouco, encontrei sobre um serviço do Officescan versão 8 chamado Web Reputation. Quando tenta-se acessar um endereço na web, este serviço checa primeiramente a classificação do site em um banco de dados online da Trend; se o site estiver reportado como perigoso (spyware, phishing, etc), o acesso ao mesmo é bloqueado.
O que estava acontecendo neste caso é que o antivírus não conseguia acessar o banco de dados online para obter a classificação do site, pois a autenticação ainda não havia ocorrido. Assim, o acesso só era liberado para o gateway (e, por consequência, para a autenticação) após o antivírus esgotar as tentativas de classificação do site.
Verificando a configuração do serviço, encontrei uma opção na qual eram informados alguns endereços que eram classificados como confiáveis sem a necessidade de consulta ao banco de dados online. Assim, liberamos o site da empresa, e mais alguns sites que geralmente são utilizados como página inicial dos navegadores.
Após isso, os problemas de velocidade nos primeiros acessos à Internet foram resolvidos, e a paz voltou a reinar na rede.
Conclusão
Por mais que uma determinada tecnologia seja difundida na maioria dos ambientes corporativos, sempre encontramos particularidades em cada um; e, por causa disso, soluções "empacotadas" nem sempre funcionam. Devemos entender o ambiente como um todo e sugerir as soluções adequadas.
Como vimos, a análise de tráfego foi decisiva na resolução deste problema e, somente após entender cada um dos componentes que compunham a solução de segurança da empresa, é que a solução adequada pode ser aplicada.
Até a próxima!