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.
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.
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.
Nenhum comentário:
Postar um comentário