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 https://www.sysinternals.com/

- Request:

Command: GET

- URI: https://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: https://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:

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: