Aula 6 - Estudo de protocolos das camadas de aplicação e de transporte

Prévia do material em texto

Gerência e Análise de Redes
Aula 6 - Estudo de protocolos das camadas de aplicação e
de transporte
INTRODUÇÃO
Nesta aula, você aprenderá a analisar protocolos de camada de aplicação como o Telnet, o FTP, o SMTP e o DNS através de experimentos práticos.
Para a análise de cada um desses protocolos, será usado o software Wirshark. Com ele, capturaremos PDUs (packet data units) de cada um dos
protocolos de aplicação citados, e realizaremos uma depuração passo a passo do signi�cado de cada PDU, bem como de sua relação com os
comandos dados pelos usuários/clientes.
Bons estudos!
OBJETIVOS
Aplicar os conceitos de modelos de camadas para depurar a aplicação de terminal remoto (Telnet) e para aplicação de correio eletrônico (SMTP);
Aplicar os conceitos de modelos de camadas para depurar a aplicação de transferência de arquivos (FTP);
Aplicar os conceitos de modelos de camadas para depurar a aplicação de resolução de nome das Internet (DNS).
TELNET
O Telnet é um protocolo padrão de camada de aplicação da internet. Seu objetivo é permitir que usuários usem um terminal de linha de comando
para enviar comandos a servidores remotos, conforme mostrado no esquema a seguir.
Fonte da Imagem:
Observe:
Os comandos são digitados no lado cliente (direita) e transmitidos ao servidor para ser executado lá (esquerda).
As mensagens de retorno de comandos são enviadas de volta ao cliente e apresentadas em seu terminal de linha de comando local (direita).
O Telnet se apoia em uma conexão TCP (glossário) (camada de transporte) para enviar dados em formato texto puro (ASCII), caractere a caractere.
Fonte da Imagem:
É importante saber:
Frequentemente, o TELNET é visto como um protocolo de camada de aplicação dos bytes digitados pelo usuário através de uma conexão TCP até o
aplicativo servidor.
Quando o aplicativo servidor gera bytes, eles também são transferidos pela mesma conexão TCP em que o cliente enviou dados.
As especi�cações básicas do Telnet estão disponíveis no RFC (glossário) 854, enquanto as numerosas opções são descritas nos RFC 855 a 861.
Nesta aula, usaremos o Telnet para estabelecer conexão TCP com determinados servidores (como SMTP), com o objetivo de analisar em detalhes o
funcionamento desses protocolos. Isso é possível pois os protocolos públicos de camada de aplicação da internet geralmente trocam mensagens
texto em ASCII para enviar comandos/respostas entre o cliente e o servidor.
Tendo em mente que o Telnet se propõe exatamente a enviar bytes de texto ASCII entre as duas pontas conectadas, então a aplicação do Telnet para
análise mais detalhada de protocolos de aplicação se torna natural.
WIRESHARK
Vamos, então, primeiramente, usar o Wireshark para capturar o tráfego de uma sessão Telnet e analisarmos os PDUs (Packet Data Units) (glossário)
capturados e, assim, compreendermos o funcionamento do Telnet.
Para esse experimento, usaremos um cenário que envolve um cliente Telnet rodando via terminal do Windows 10 (IP: 192.168.10.176) e um servidor
Telnet rodando em uma workstation com o sistema operacional HP-UX (IP: 192.168.10.25). A sessão Telnet que analisaremos é bastante simples e
envolve apenas dois passos:
No Wireshark, habilitamos dois �ltros:
A imagem a seguir apresenta o terminal de login Telnet resultante do comando dado no passo 1, bem como o resultado da captura dos PDUs
transmitidos até o momento em que a tela de login é mostrada.
Os três primeiros PDUs estão relacionados ao estabelecimento de conexão TCP, na camada de transporte, entre o host cliente e o host destino (porta
Telnet: 23), através do Three-Way Handshake (apresentação de três vias) já estudado neste disciplina.
Fonte da Imagem:
Observe:
Logo, em seguida, o Telnet gera vários pacotes de dados (suprimidos aqui por questão de espaço) relativos ao acordo de opções usadas na sessão
Telnet e na transferência do texto a ser apresentado na tela de login.
Após o login, iniciamos o passo 2, que consistiu em digitar o comando ls.
PDUs gerados pelo comando ls
Como mostrado na imagem abaixo, esse comando gerou seis PDUs. Vamos ver agora cada um deles.
PDU 1
O PDU de número 1, em destaque na imagem, é uma mensagem de dados trafegando no sentido cliente-servidor. O conteúdo dessa mensagem é o
primeiro caractere do comando ls, ou seja, o l. Essa mensagem está encapsulada em um segmento UDP (glossário).
PDU 2
O PDU de número 2, em destaque na imagem abaixo, é a mesma mensagem Telnet, com o mesmo conteúdo, mas trafegando no sentido servidor-
cliente.
Essa é uma característica do protocolo Telnet. Cara caractere digitado pelo usuário é transmitido em um PDU ao servidor e, após o aplicativo Telnet
servidor receber o caractere/byte, ele emite um eco com o mesmo caractere de volta ao cliente.
Quando o usuário digita um caractere, o aplicativo Telnet o transmite ao servidor e só apresentará o caractere digitado na tela do cliente quando o
eco chegar.
Você deve se sentir seguro com o fato de que esse processo nada tem a ver com a transmissão con�ável do TCP. Ao contrário, serve apenas para
que mesmo um usuário leigo perceba como está o tempo de ida e volta entre o cliente e o servidor e, ao ver o caractere apresentado na tela, se sinta
seguro com o fato de que o caractere foi compreendido pelo processo Telnet servidor.
PDU 3
Em seguida, no PDU de número 3, destacado na imagem abaixo, observamos que o TCP (camada de transporte) do cliente automaticamente emitiu
uma con�rmação ao TCP do servidor para informá-lo que o cliente recebeu corretamente o eco.
PDU 4
O PDU de número 4, em destaque na imagem abaixo, é uma mensagem de dados trafegando no sentido cliente-servidor.
O conteúdo dessa mensagem é o segundo caractere do comando ls, ou seja, o s. Essa mensagem está encapsulada em um segmento UDP.
PDU 5
O PDU de número 5, em destaque na imagem abaixo, é uma mensagem Telnet que carrega o eco do segundo caractere do comando ls.
PDU 6
Em seguida, no PDU de número 6, destacado na imagem abaixo, observamos que o TCP (camada de transporte) do cliente automaticamente emitiu
uma con�rmação ao TCP do servidor para informá-lo que o cliente recebeu corretamente o eco do segundo caractere transmitido.
, Em resumo, o Telnet seguirá agindo da forma que vimos acima para cara caractere digitado pelo usuário no terminal cliente., , Quando o usuário terminar de
emitir comandos a serem executados pelo Telnet Servidor, ele pode entrar com o comando exit, que fará com que TCP (camada de transporte) do lado cliente e do
lado servidor �nalizem a conexão e terminem a sessão Telnet.
CORREIO ELETRÔNICO
A seguir, examinaremos os protocolos de camada de aplicação que estão no núcleo do correio eletrônico da internet. Mas, antes de entrarmos nessa
discussão, vamos analisar uma visão geral do sistema de correio da internet e de seus componentes principais.
A imagem abaixo apresenta uma visão do sistema de correio da internet.
Veja que há três componentes principais:
AGENTES DE USUÁRIO (CLIENTES DE E-MAIL)
Permitem que usuários leiam, respondam, encaminhem, salvem e componham mensagens.
O Thunderbird, o Microsoft Outlook, o Windows Mail e o Apple Mail são alguns exemplos de clientes de e-mail.
SERVIDORES DE CORREIO
Quando um usuário termina de compor seu e-mail, seu cliente de e-mail envia a mensagem para seu servidor de correio usando o protocolo SMTP.
Nesse servidor, a mensagem é colocada em sua �la de mensagens de saída. Quando chegar a hora dessa mensagem ser servida, ela será transferida para o
servidor de e-mail do usuário destino através do protocolo SMTP.
Servidores de correio formam o núcleo da infraestrutura do e-mail. Cada destinatário tem uma caixa postal (caixa de entrada, inbox) localizada em um desses
servidores.
Quando um usuário quer ler uma mensagem, seu cliente de e-mail transfere a mensagem de sua caixa postal, localizada em seu servidor de correio.
SMTP (SIMPLE MAIL TRANSFER PROTOCOL)
O esquema a seguir mostra que uma mensagem típica inicia sua jornada no agente de usuário do remetente, vai até seu servidor de correio(via SMTP) e viaja até
o servidor do destinatário (também via SMTP), onde é depositada na caixa postal.
Quando o usuário destinatário quer acessar as mensagens de sua caixa postal, ele se conecta (via POP3 ou IMAP) ao servidor de correio que contém sua caixa
postal.
Todos os protocolos envolvidos nessa comunicação usam o TCP na camada de transporte.
ANÁLISE DO SMTP
Nossa análise do SMTP envolverá um cenário simples em que o usuário opera um cliente de e-mail a partir de seu host (192.168.10.176), de onde
redige um e-mail destinado ao destino@servidor.com. O endereço de remetente do e-mail é remetente@meuservidor.com. O assunto do e-mail é
AssuntoTeste.
Fonte da Imagem:
Observe:
A imagem mostra a captura de PDUs logo após o usuário remetente clicar no botão “enviar” de seu cliente de e-mail.
Como nosso objetivo é analisar somente o SMTP (camada de aplicação), os segmentos TCP foram marcados com uma cor escura, para que
possamos nos concentrar unicamente nas mensagens de camada de aplicação do SMTP. Ou seja, para manter nossa discussão na camada de
aplicação, ignoraremos o three-way handshake do TCP, que precede a troca de dados SMTP, bem como qualquer outro segmento de controle TCP.
PDUs capturados pelo Wireshark
Imediatamente após o estabelecimento da conexão TCP (portas 25 - desatualizada ou 587 – padrão atual), os seguintes PDUs foram capturados
pelo Wireshark:
PDU 63
O servidor SMTP enviou ao cliente a mensagem “220 meuservidor.com ESMTP Post�x”.
Essa é uma mensagem de boas-vindas que informa ao cliente à qual servidor ele se conectou, bem como o protocolo
de envio de e-mails que ele usa (ESMTP – SMTP Extendido) e, ainda, qual é o software servidor de e-mail usado
(Post�x).
PDU 64
O cliente envia a mensagem SMTP “EHLO 192.168.10.176”, se identi�cando ao servidor.
PDU 66
O servidor transmite ao cliente a mensagem SMTP “250 correio.ien.gov.br | 250 PIPELINE...”.
PDU 67
O cliente informa ao servidor que tem um e-mail a ser entregue, cujo remetente é remetente@meuservidor.com.
PDU 68
O Servidor informa ao cliente que compreendeu a mensagem e que o cliente pode enviar o próximo comando.
PDU 69
O cliente informa ao servidor que tem um e-mail a ser entregue a destino@servidor.com.
PDU 70
O servidor informa ao cliente que compreende e conhece o destinatário do e-mail.
PDU 71
O cliente envia a mensagem SMTP “DATA” para informar ao servidor que começará a enviar o conteúdo do e-mail.
PDU 72
O servidor informa ao cliente que tudo bem, e que, ao �nal do conteúdo do e-mail, o cliente deve enviar os “
” (dois pares de caracteres Carriage Return e Line Feed) para indicar que o conteúdo do e-mail
acabou.
PDU 74, 75, 77 e 79
O cliente emite três pacotes de dados com o conteúdo do e-mail, com tamanhos de 310, 1590 e 258 Bytes,
respectivamente, e segue a instrução de preencher o �nal do e-mail com “ ”, para que o servidor
identi�que que o conteúdo do e-mail terminou.
PDU 81
O servidor de e-mail informa ao cliente que a mensagem foi recebida, compreendida, foi marcada com a identi�cação
B0C513F82 e que será colocada na �la para ser enviada ao “servidor.com” assim que possível.
PDU 82
O cliente envia a mensagem SMTP “QUIT” para informar ao servidor que deseja terminar a sessão.
PDU 85
O servidor SMTP envia a mensagem “Bye” ao cliente informando que compreendeu o término da sessão e que está ok
para a �nalização da sessão.
Saiba mais!
, Embora nossa análise de PDUs trocados durante uma sessão SMTP de envio de e-mail tenha parado por aqui, tenha em mente que outra sessão similar a essa
será iniciada partindo de “meuservidor.com” para “servidor.com”., , Nesse momento, a mensagem B0C513F82 será passada de um servidor para outro e será
armazenada na caixa de entrada do usuário destino.
A porta 25 do SMTP
A porta 25 do SMTP, por ser utilizada há mais tempo, possui uma vulnerabilidade maior a ataques e interceptação de mensagens, além de não exigir
autenticação para envio das mensagens, ao contrário da 587 que oferece essa segurança a mais.
A medida foi tomada através do CGI, a �m de minimizar a quantidade de SPAMs que circulam por domínios brasileiros, a partir da constatação de
que, no início de 2010, o Brasil estava em segundo lugar no ranking mundial de envio de SPAMs, devido a vulnerabilidades a malwares ou
con�gurações feitas incorretamente.
Fonte da Imagem:
Segundo o Comitê Gestor da Internet, a intenção é que a porta 25 seja bloqueada, minimizando os riscos de invasão.
Por esses motivos, optou-se por adotar a porta 587, que, para retransmissão da mensagem, utiliza autenticação do SMTP, di�cultando o uso indevido
de contas de e-mail ou de máquinas como zumbis (método bastante utilizado por spammers, em que máquinas de usuários aleatórios são usadas
como emissores de SPAM, implicando na prática de Spoo�ng, problema comum com usuários de e-mail).
FTP
Em uma sessão FTP típica (como mostra o esquema), o usuário, sentado à frente de um hospedeiro (o local), quer transferir arquivos de ou para um
hospedeiro remoto. Para acessar a conta remota, o usuário deve fornecer uma identi�cação e uma senha. Após fornecer essas informações de
autorização, pode transferir arquivos do sistema local de arquivos para o sistema remoto e vice-versa, conforme ilustra a imagem a seguir.
A imagem abaixo ilustra a sessão FTP usada para gerar os PDUs a serem capturados pelo Wireshark que alimentarão nossa análise desse
interessante protocolo da camada de aplicação.
O cliente se conecta em um servidor FTP (192.168.10.15), realiza o login, entra no diretório teste, lista os arquivos deste diretório e realiza download
do arquivo “arquivo.txt”. Observe:
Relação entre os comandos digitados pelo usuário e os PDUs
transmitidos pela rede
A seguir, analisaremos a relação entre os comandos digitados pelo usuário e os PDUs desta sessão transmitidos pela rede:
“ftp 192.168.10.25” (inicia o aplicativo FTP e solicita uma sessão FTP com o servidor 192l168.10.25)
PDU 4: Após estabelecimento da conexão TCP, o servidor envia o texto da tela de login a ser apresentado para o
cliente FTP;
PDU 6: O cliente FTP tentou ajustar o encoding de dados para o padrão UTF08;
PDU 7: O servidor FTP informou que não conhece esse encoding.
“Usuário (192.168.10.25 none)): joao”
PDU 9: O cliente envia a mensagem FTP “USER joao” informando que o usuário se identi�cou, via teclado, como
usuário João;
PDU 10: O servidor informa que o login deste usuário requer senha.
“331 Password required for ihs. Senha:”
PDU 12: O cliente envia a mensagem FTP “PASS minhasenha” informando que o usuário digitou a senha
“minhasenha”;
PDU 13: O servidor enviou mensagem FTP informando que o login do usuário foi efetuado com sucesso. O cliente
apresenta a respectiva mensagem na tela.
“cd teste”
PDU 15: o cliente FTP enviou a mensagem FTP “CWD teste”, o que informa ao servidor que o usuário deseja trocar de
diretório para o diretório teste;
PDU 16: O servidor envia a mensagem FTP “250 CWD Sucessfull” para informar ao cliente que a troca de diretório foi
efetuada com sucesso. O cliente apresenta a mensagem “250 CWD command successful” ao usuário.
“ls”
PDU 18: O cliente envia a mensagem FTP “PORT 192,168,10,176,194,182” ao servidor para informar que espera
receber a listagem via uma nova conexão TCP no IP 192.168.10.176 (IP do cliente) e porta (194*256 + 182 = 49846).
Esse é o método padrão de�nido pelo FTP para que o cliente informe ao servidor para que porta o servidor deve se
conectar para enviar os dados da listagem solicitada);
PDU 19: O servidor envia a mensagem FTP “200 PORT command successful” para informar ao cliente que ele
entendeu as instruções sobre qual porta do cliente deve ser usada para enviar a listagem de arquivos solicitada. O
cliente apresenta essa mensagem na tela;
PDU 20: Agora que o servidor entende como enviar dados ao cliente, o cliente efetivamente envia a mensagem FTP
“NLST” pedindo que o servidor lhe envie a listagem de arquivos imediatamente;
PDU 26: O servidor informa (“150 Opening ASCII mode data connectionfor �le list”) ao cliente mostrando a
representação de dados que será usada para transferência da listagem de arquivos. O cliente apresenta essa
mensagem ao usuário para que ele saiba como se dará a transmissão da listagem de arquivos;
PDU 27: O servidor envia um pacote de dados FTP (ftp-data) contendo a listagem de arquivos solicitada pelo cliente.
Ao receber a mensagem, o cliente apresenta a listagem de arquivos ao usuário. Nesse exemplo, o único arquivo
presente no diretório teste é “arquivo.txt”;
PDU 31: O servidor envia a mensagem FTP “226 Transfer Complete” informando ao cliente que terminou a
transferência da listagem de arquivos com sucesso. O cliente FTP envia essa mensagem ao usuário, juntamente com
o total de bytes recebidos e a taxa de transmissão.
“get arquivo.txt” (o usuário solicita o download de arquivo.txt.)
PDU 35: O cliente envia a mensagem FTP “PORT 192,168,10,176, 194,183” ao servidor, instruindo-o a estabelecer uma
nova conexão TCP via porta (194*245 + 183 = 49487) que será usada para o envio de arquivo.txt;
PDU 36: O servidor envia a mensagem FTP “200 PORT command successfull” para informar que compreendeu a
informação de porta sobre a nova conexão TCP para envio de dados. O cliente apresenta essa mensagem ao usuário;
PDU 37: O cliente envia a mensagem FTP “RETR arquivo.txt” ao servidor para efetivamente solicitar que o servidor
trans�ra o arquivo em questão ao cliente;
PDU 40: O servidor informa (“150 Opening ASCII mode data connection for �le list”) ao cliente mostrando a
representação de dados que será usada para transferência da listagem de arquivos. O cliente apresenta essa
mensagem ao usuário para que ele saiba como se dará a transmissão da listagem de arquivos;
PDU 41: O servidor envia um pacote de dados FTP (ftp-data) contendo o arquivo “arquivo.txt” pelo cliente. Ao receber
a mensagem, o cliente inicia a gravação do arquivo recebido no disco rígido local;
PDU 47: O servidor envia a mensagem FTP “226 Transfer Complete” informando ao cliente que terminou a
transferência da listagem de arquivos com sucesso. O cliente FTP envia essa mensagem ao usuário, juntamente com
o total de bytes recebidos e a taxa de transmissão.
Caraterística interessante do FTP
A esta altura você deve ter notado que o FTP tem uma caraterística muito interessante: os comandos são enviados por uma conexão TCP de
controle e, sempre que há necessidade de troca de dados (como a listagem ou download de arquivos), uma nova conexão TCP é aberta para
transferência de dados, conforme indicado no esquema abaixo.
Fonte da Imagem:
Observe:
O servidor usa a porta 21 para receber conexões FTP e para trocar mensagens de controle, e usa a porta 20 para receber dados.
Instantes antes de iniciar um download ou listagem de arquivos, o cliente deve informar ao servidor qual será a porta do lado do cliente usada para
transferir dados.
Em nosso experimento, as portas escolhidas pelo cliente foram 49846, para listagem de arquivos, e 49847, para download de arquivo.txt.
DNS
Fonte da Imagem:
A última análise que realizaremos nesta aula tem como alvo o protocolo de camada de aplicação DNS (Domain Name System).
O objetivo do DNS é facilitar a vida dos usuários através da tradução de nomes de hosts (como o www.google.com) em endereços IPs (por exemplo,
216.58.22.68).
Como os usuários leigos têm uma relação muito mais amigável com os nomes de hosts do que com os endereços IPs, o DNS acabou se tornando
importante para diversos outros protocolos de aplicação, incluindo a web e o e-mail.
O DNS é um protocolo interessante, pois é um componente fundamental da infraestrutura da internet, mas implementado na camada de aplicação.
Análise de PDUs gerados por uma aplicação DNS
Para a análise de PDUs gerados por uma aplicação DNS, vamos considerar o cenário simpli�cado onde um usuário abre um terminal de comandos e
digita o comando “ping www.estacio.br”.
O ping é uma aplicação que testa a conectividade entre o localhost e o host informado no comando, bem como mede o atraso de ida e volta.
Esse experimento está ilustrado na parte superior da imagem abaixo.
Fonte da Imagem:
Observe:
Logo após digitar o comando e teclar , a aplicação ping precisa obter o endereço IP relativo ao hostname www.estacio.br. Para isso, é gerada uma
consulta DNS direcionada ao endereço IP do servidor DNS local con�gurado no host do cliente.
Como mostrado no lado direito da imagem, o primeiro pacote gerado após o início do ping é o PDU de número 1. Este segmento UDP é direcionado à
porta destino 53, que é a porta padrão DNS. O endereço IP destino do PDU é 192.168.1.32, indicando que esse é o servidor DNS con�gurado na
máquina do usuário.
A identi�cação de transação é 0x595f. Cada sessão DNS possui uma identi�cação única. Isso é importante para quem analisa PDUs de sessões
DNS, pois é através desse valor que é possível identi�car quais PDUs DNS pertencem à mesma sessão.
O Campo Queries do Cabeçalho DNS informa que o hostname que se deseja traduzir é www.estacio.br.
Ainda na imagem, vemos que o PDU de número 2 foi recebido vindo do servidor DNS local com destino ao host do usuário. Os detalhes dessa
resposta DNS estão apresentados na imagem.
O transaction ID é 0x595f, o mesmo valor do transaction ID da consulta DNS. Isso con�rma que esta é a resposta DNS para a consulta DNS que
analisamos.
Atenção!
, Lembre-se da análise do DHCP realizada na aula passada. O DHCP é capaz de, automaticamente, informar ao host do usuário qual é o endereço IP do servidor
DNS.
Mais abaixo, na mesma imagem, marcamos o ponto em que o endereço IP do host www.estacio.br é de fato apresentado.
Dois IPs foram fornecidos: 200.123.199.32 e 200.123.199.19.
Fonte da Imagem:
Observe:
Se você conferir na imagem, onde é apresentada a linha de comando e os retornos do comando ping, verá que o processo ping escolheu o endereço
IP 200.123.199.19 para o envio da consulta DNS.
Uma das razões para consulta DNS a um hostname, para devolver vários IPs, é fornecer várias opções para que o cliente possa escolher uma delas à
sua vontade. Com isso, distribui-se a carga do tráfego até os diversos servidores disponíveis.
Em nosso caso, a consulta DNS revelou que há dois servidores atendendo pelo nome www.estacio.br.
Chegou a hora de exercitar o que você aprendeu!
Suponha que você queira usar um aplicativo que lhe permita trocar mensagens, via linha de comandos, com o processo servidor de diversos
protocolos de aplicação, como o HTTP (glossário), SMTP ou FTP.
Marque abaixo a opção que representa o melhor aplicativo para tal objetivo:
"Thunderbird"
Apache
"Microsoft Edge"
"Chrome"
"Telnet"
Justi�cativa
, Você poderá, também, exercitar os conhecimentos que aprendeu nesta aula através de uma lista de exercícios que preparamos., , Para acessar à lista de
exercícios, clique aqui (galeria/aula6/docs/a06_t09.pdf).
https://stecine.azureedge.net/webaula/estacio/gon645/galeria/aula6/docs/a06_t09.pdf
https://stecine.azureedge.net/webaula/estacio/gon645/galeria/aula6/docs/a06_t09.pdf
Glossário
TRANSMISSION CONTROL PROTOCOL (TCP)
Protocolo de Controle de Transmissão da Internet.
REQUEST FOR COMMENTS (RFC)
Documentos de domínio público que de�nem cada padrão/protocolo usado pela Internet. Esses documentos estão gratuitamente disponíveis na internet.
PACKET DATA UNIT (PDU)
Unidade de pacote de dados (unidade de dados).
USER DATAGRAM PROTOCOL (UDP)
Protocolo de Datagramas do Usuário.
HYPER TEXT TRANSFER PROTOCOL (HTTP)
Protocolo padrão para navegação web da Internet.