quinta-feira, 10 de abril de 2014

Troubleshoot de rede – Analisador de Pacotes (sniffer)


Pessoal,

Esta semana precisei estudar um pouquinho a mais o Wireshark para identificar uns problemas na empresa e encontrei algumas coisas muito boa.

Abaixo colocarei algo mais prático para identificação de problemas de rede com o Wireshark.

Sniffer, ferramenta do bem ou do mal?
Das ferramentas disponíveis no mercado, como Wireshark, Sniffer Pró, TCP Dump, etc, todas realizam basicamente as mesmas tarefas básicas:
• Captura – capturar os dados binários que entram ou saem da placa de rede;
• Conversão – converter os dados binários da captura em informações legíveis;
• Análise – indicar problemas ou inconsistências relacionadas aos dados capturados.
Através da captura e análise dos dados coletados, um administrador de redes conseguirá identificar a causa do problema, e agir de acordo para resolvê-lo. Da mesma forma que, qualquer informação considerada como confidencial ou sigilosa, se não estiver devidamente protegida (criptografada) poderá ser lida por qualquer um, minando o esquema de segurança da informação adotada pela empresa.
Vamos à prática!
Vamos a um exemplo prático de como o sniffer pode ser utilizado na resolução de um problema.
Cenário: Determinada aplicação apresenta lentidão durante a execução de algumas rotinas solicitadas pelos usuários. A aplicação em questão utiliza dois servidores localizados no mesmo CPD, sendo um servidor Web e um servidor de banco de dados.
Objetivo: Identificar se a causa de lentidão é algum problema de Hardware, Rede, ou dos Softwares envolvidos.
Para sermos mais objetivos com este artigo, não abordaremos as ferramentas de análise de Hardware do Servidor e análise da rede, e nos focaremos no uso do sniffer para identificar se existe problema na Aplicação ou na sua interação com a rede.
Neste artigo, foi utilizada a ferramenta Wireshark, devido a sua facilidade de uso e sofisticados recursos de filtragem relatórios; além de ser uma ferramenta gratuita.
Retransmissão de pacotes
Caso ocorra algum erro durante a transmissão dos pacotes de dados pela rede, o servidor precisará reenviar esta informação que foi perdida, isto se chama Retransmissão de pacotes TCP. Retransmissão de pacotes pode ser considerada “normal”, desde que mantenha uma proporção baixa, em relação ao montante de pacotes enviados.
RTT elevado
Round Trip Time (RTT) é o tempo gasto entre o envio do pacote e o recebimento da confirmação de que foi entregue, ou Acknowledge (ACK). O RTT é recalculado sempre que uma transmissão se fizer necessária, desta forma se tivermos um valor de RTT muito alto, significa que neste momento, estamos enfrentando um congestionamento de rede, indicando que não é problema na aplicação, e sim que temos pouca banda de rede disponível.
Lentidão no Banco de dados
Um problema mais difícil de ser detectado é quando nos deparamos com erros que não são detectados pelo sniffer, porque não indicam erros de protocolo ou comunicação de rede, mas que devem ser analisados e interpretados pelo analista de rede.
No exemplo abaixo, não existem atrasos na entrega dos pacotes de rede, o que acontece é que após ter sido enviada uma solicitação do servidor de aplicação para o servidor Banco de Dados, o retorno com os resultados ocorre muito depois da aplicação já te retornado uma mensagem de erro para o usuário.
Como podemos perceber, em várias situações o problema de lentidão, falhas e outros erros não são gerados pelo aplicativo em sí, isto tudo é apenas o reflexo e consequência de outro problema.

Vejam os principais filtros para usar no Wireshark.

ExemplosMostrar apenas SMTP ( porta 25 ) e tráfego ICMP:

     
tcp.port eq 25 ou icmpMostrar apenas o tráfego na LAN ( 192.168 ) , entre as estações de trabalho e servidores - sem Internet:

    
IP.src == 192.168.0.0/16 e 192.168.0.0/16 ip.dst ==Tampão TCP completo - Fonte está instruindo Destino para parar de enviar dados

     
tcp.window_size == 0 && tcp.flags.reset ! = 1Filtre em Windows - filtrar o ruído , enquanto assistia Windows Client - trocas DC

     
smb | | NBNS | | dcerpc | | NBSS | | dnsWorm Sasser : - O Sasser realmente fez -

      
ls_ads.opnum == 0x09Igualar pacotes contendo o ( arbitrária ) sequência de 3 bytes 0x81 , 0x60 , 0x03 , no início da carga UDP , saltando o UDP cabeçalho de 8 bytes . Note-se que os valores para a sequência de bytes implicitamente estão apenas em hexadecimal. (Útil para combinar protocolos de pacotes caseiros . )

      
udp [ 08:03 ] == 81:60:03O recurso de " fatia " também é útil para filtrar por parte identificador fornecedor ( OUI ) do endereço MAC , consulte a página de Ethernet para obter mais detalhes . Assim, você pode restringir a exibição de apenas pacotes de um fabricante de dispositivo específico. Por exemplo apenas para máquinas da Dell:

      
eth.addr [ 00:03 ] == 00:06:05 BTambém é possível pesquisar por personagens que aparecem em qualquer lugar em um campo ou protocolo usando o operador de jogos .Jogo pacotes que contém a sequência de 3 bytes 0x81 , 0x60 , 0x03 em qualquer lugar do cabeçalho UDP ou carga útil :

      
udp contém 81:60:03Jogo onde pacotes SIP Para cabeçalho contém a string " a1762 " em qualquer lugar no cabeçalho :

      
sip.To contém " a1762 "O operador jogos torna possível pesquisar texto em campos de cordas e sequências de bytes utilizando uma expressão regular, usando Perl sintaxe de expressão regular. Nota : Wireshark precisa de ser construída com libpcre , a fim de ser capaz de usar o operador de jogos .Solicitações HTTP jogo onde os últimos personagens na uri são os personagens " gl = se ":

      
http.request.uri corresponde " gl = se $"Nota: O caractere $ é um caractere de pontuação PCRE que coincide com o final de uma string , neste caso, o fim do campo http.request.uri .Filtrar por um protocolo (por exemplo, SIP) e filtrar IPs indesejados :

  
IP.src ! = xxx.xxx.xxx.xxx && ip.dst ! = xxx.xxx.xxx.xxx && gole[ Sinta-se livre para contribuir mais]gotchasAlguns campos de filtro jogo contra vários campos de protocolo. Por exemplo, " ip.addr " partidas contra tanto a origem eo destino endereços IP no cabeçalho IP . O mesmo é verdadeiro para os " tcp.port " , " udp.port " , " eth.addr " , e outros. É importante notar que

     
ip.addr == 10.43.54.65

    
é equivalente a

     
IP.src == 10.43.54.65 ou 10.43.54.65 ip.dst ==Este pode ser , em alguns casos contra-intuitivo . Suponha que queremos filtrar todo o tráfego de e para 10.43.54.65 . Podemos tentar o seguinte:

     
ip.addr ! = 10.43.54.65

    
o qual é equivalente a

     
IP.src ! = 10.43.54.65 ou ip.dst ! = 10.43.54.65Isso se traduz em " passar todo o tráfego , exceto para o tráfego com um endereço IPv4 fonte de 10.43.54.65 e um endereço IPv4 destino de 10.43.54.65 " , o que não é o que queríamos .Em vez disso , precisamos negar a expressão , assim:

     
! ( Ip.addr == 10.43.54.65 )

    
o qual é equivalente a

     
! ( IP.src == 10.43.54.65 ou ip.dst == 10.43.54.65 )Isso se traduz em " passar qualquer tráfego, exceto com um endereço IPv4 fonte de 10.43.54.65 ou um endereço IPv4 destino de 10.43.54.65 " , que é o que queríamos


Desculpe a tradução pois foi feita pela Google Translator.