Utilizando o Network Monitor 3 para Entender o Tráfego HTTP


Por: Yuri Diógenes


 


1. Introdução


 


Algumas vezes recebo pergunta de clientes, alunos ou outros profissionais de TI acerca de como fazer para ler e entender capturas de rede. Minha resposta sempre é: para ler tráfego de rede é necessário saber como o protocolo a qual se está analisando funciona. Em outras palavras, não adianta saber muito sobre a ferramenta de captura de tráfego e não entender sobre o protocolo. O conhecimento do protocolo é essencial para saber o que esperar durante a leitura do pacotes. A verdade é que é difícil saber todos detalhes de todos protocolos e é comum pesquisar sobre um determinado protocolo durante a leitura de arquivo de captura de rede. Porém, o que é indispensável é ter uma boa base da arquitetura TCP/IP. Desta forma, este artigo parte do pressuposto que você tem esta base necessária.


 


Para este artigo iremos usar o protocolo HTTP, que é um dos protocolos que usamos diariamente para acessar Internet. O artigo tem como objetivo entender o tráfego HTTP através do uso da ferramenta Microsoft Network Monitor 3.


 


2. Componentes HTTP


 


O protocolo HTTP é composto basicamente de duas mensagens principais, são elas: HTTP Request e HTTP Response. Na figura abaixo temos um exemplo destas mensagens:


 



Figure 1 – HTTP Messages


 


Vejamos uma breve explicação sobre os principais campos que compões uma mensagem:


·         HTTP Version: mostra a versão do protocol HTTP usado na mensagem (ex.: HTTP 1.0 or HTTP 1.1).


·         Method: trata-se da ação que o cliente está requisitando para o servidor (ex.: GET and POST).


·         Status Code: trata-se do código que descreve o que aconteceu durante esta determinada transação (ex.: 200, 301 and 407).


·         Reason: é um complemento para o campo anterior (ex.: OK, NOT OK).


·         Headers: o conteúdo do cabeçalho (header) vai depender da versão do protocolo HTTP em uso. Por exemplo, o protocolo HTTP/1.1. tem alguns campos específicos para esta versão.


·         Body: algumas mensagem vão conter um corpo para o texto, que por sua vez é o dado em si. Porém, alguns outros tipos de mensagem não contém corpo (body).


 


Com base nesta breve explicação acerca dos principais components das mensagens HTTP, vamos utilizar o NetMon 3 para verificar o funcionamento deste protocolo.


 


3. Entendendo as Mensagens HTTP usando o Netmon3


 


Neste exemplo o servidor está tentando acessar o site www.sysinternals.com. O servidor que está tentando fazer o acesso a este site está usando o Windows Server 2003 e está atrás de um servidor Proxy (com ISA Server 2004) e usando autenticação integrada. Todo este tráfico foi capturado a partir deste servidor enquanto estava acessando este site.


 


Uma ótima forma de entender a conversa HTTP é adicionar as colunas HTTP is Request e HTTP is Response. A coluna será mostrada com o número 1 caso seja verdadeira, com isso fica fácil identificar se é uma requisição ou uma resposta HTTP.


 


 


Figura 2 – Escolhendo as colunas.


 


Para este exemplo é bem simples identificar o tráfego, porém em um cenário real, fica mais difícil chegar diretamente ao pacote que contém a requisição para a URL. O primeiro pensamento que temos é: há, vamos criar um filtro. Mas, o problema é que ao criar-se um filtro, apenas o tráfego da origem e do destino será mostrado e não é este o objetivo aqui.


 


Existe uma função bem interessante no Netmon3 que permite você usar um filtro para encontrar um pacote. Para usar esta função você precisa clicar no menu Frames e depos clicar em Find. A seguinte janela aparecerá:


 



Figura 3  – Encontrar um pacote basedo em um filtro.


 


Neste caso queremos encontrar um pacote que atenda o seguinte critério:


 


Contains(http.request.URI,”sysinternals.com”)


 


Após digitar este filtro e clicar no botão Find o pacote que atende esta requisição será selecionado. Após isso nós podemos fechar esta janela e revisar o pacote. Aqui o cabeçalho HTTP para este pacote:


 



– Http: Request, GET http://www.sysinternals.com/


  – Request:


     Command: GET


   – URI: http://www.sysinternals.com/


    + Uri:


     ProtocolVersion: HTTP/1.0


     Accept:  image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*


     Accept-Language:  en-us


     UA-CPU:  x86


     Proxy-Connection:  Keep-Alive


     UserAgent:  Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1; .NET CLR 1.1.4322)


     Host:  www.sysinternals.com


     HeaderEnd: CRLF


 


Como você pode ver, este é o pacote HTTP que faz a requisição da mensagem e alguns dos componentes que foram explicados anteriormente aparecem neste pacote. Vamos verificar a resposta do servidor:


 



– Http: Response, HTTP/1.1, Status Code = 301


  – Response:


     ProtocolVersion: HTTP/1.1


     StatusCode: 301, Moved permanently


     Reason: Moved Permanently


     Via:  1.1 SRVISA


     Connection:  Keep-Alive


     Proxy-Connection:  Keep-Alive


     ContentLength:  31


     Date:  Sun, 26 Aug 2007 15:05:10 GMT


     Location:  http://www.microsoft.com/technet/sysinternals


     ContentType:  text/html


     Server:  Microsoft-IIS/6.0


     XPoweredBy:  ASP.NET


     Set-Cookie:  ASPSESSIONIDCCRASDTB=OKKIMCCDOMFAEPIPJCLNPEBN; path=/


     Cache-control:  private


     HeaderEnd: CRLF


  + payload: HttpContentType =  text/html


 


Nesta mensagem de resposta HTTP é realmente importante enfatizar um ponto em particular, que é o código do status (Status Code). O código para esta resposta é 301, este número em sí já diz muita coisa. Por isso a importância de entender o significado destes códigos baseado no intervalo do número. Este intervalo está descrito na tabela abaixo:


 




















Status Code


Means


200 – 299


Success


300 – 399


Redirection


400 – 499


Erro no lado do cliente


500 – 599


Erro no lado do servidor


 


Os parses do netmon3 para o protocol HTTP tem a definição dos principais códigos. Para conferir estes códigos basta clicar na guia Parses, clicar em Protocols e em seguida clicar em HTTP. No painel da direita as definições iram aparecer.


 



Figura 4 – Parses do Protocolo HTTP no Netmon3.


 


Como está é uma resposta de redirecionamento, o campo “location” tem o local onde a página está localizada. Esta mensagem é apresentada para o cliente, que baseado nesta mensagem vai fazer uma nova requisição HTTP para esta URL.


 


4. Conversação HTTP com Netmon3


 


A característica de conversação do Netmon3 permite que você visualize os frames agregados pela mesma conexão. Para este exemplo, vejamos os frames agregados para a requisição da URL www.microsoft.com:


 



Figura 5 – Filtrando pela conversão.


 


Este filtro pode ajudar bastante no entendimento de toda a conexão entre o cliente e o servidor durante esta comunicação. Uma outra forma de personalizar este filtro é clicando no botão direito na conversão e escolhendo a opção “Copy Conversation Filter to Clippboard” como mostrado na figura 5.


 


Após revisar esta conversação podemos ver outro código retornado pelo servidor, desta vez com um erro no lado do cliente:


 



– Http: Response, HTTP/1.1, Status Code = 407


  – Response:


     ProtocolVersion: HTTP/1.1


     StatusCode: 407, Proxy authentication required


     Reason: Proxy Authentication Required ( The ISA Server requires authorization to fulfill the request. Access to the Web Proxy filter is denied.  )


     Via:  1.1 SRVISA


   – ProxyAuthenticate:  Negotiate


      WhiteSpace: 


      AuthenticateData: Negotiate


   – ProxyAuthenticate:  Kerberos


      WhiteSpace: 


      AuthenticateData: Kerberos


   – ProxyAuthenticate:  NTLM


      WhiteSpace: 


      AuthenticateData: NTLM


     Connection:  Keep-Alive


     Proxy-Connection:  Keep-Alive


     Pragma:  no-cache


     Cache-Control:  no-cache


     ContentType:  text/html


     ContentLength:  4106 


     HeaderEnd: CRLF


  + payload: HttpContentType =  text/html


 


A razão pela qual esta requisição foi considerada com erro é devido ao fato de que o servidor ISA requerer autenticação para acesso a Internet. Como padrão o primeiro pacote do Internet Explorer será enviado sem credenciais, então é esperado de fato termos tal pacote voltando para o cliente.


Após a resposta do servidor, o cliente vai enviar um outro pacote com as credenciais usando NTLM ou Kerberos, isso vai depender da configuração.


 


5. Informações Gerais


 


Existem vários commandos que podem ser usados para obter maiores informações do tráfego HTTP. Vejamos alguns deles:


 

















Filtro


Explicação


contains(Http.Response.StatusCode,”301″)


Mostra todos pacotes HTTP onde o código de status é 301


Property.HttpIsRequest


Mostra todos pacotes de requisições HTTP


Property.HttpPragma


Mostra todos pacotes HTTP que não podem ser colocado em cache. Para maiores informações veja a definição do campo Pragma, em HTTP Field definition.


 


 

Comments (1)

  1. Fabiano says:

    Show o Artigo Yuri.

    Parabens!!