Universidade do Estado do Rio de Janeiro

Faculdade de Engenharia
Redes de Comunicações 1 / Teleprocessamento e Redes de Computadores

Trabalho 1

Aluno: Vitor Santos Pereira

11/05/2021
1. Alguns protocolos particulares aqui serão detalhados na cadeira Redes de
Comunicações 2 e outros aparecem em plataformas Windows usando browsers líderes
de uso (me refiro particularmente ao Google Chrome). Por ora, seu trabalho é produzir
um texto de pesquisa sobre o que é, onde se aplica e eventualmente, se você
conseguir, um trecho de WireShark rodado em seu ambiente computacional em modo
promíscuo em que ele esteja registrado (opcional). São eles:

• MNDS - Multicast Domain Name Service

• SSDP – Simple Service Discovery Protocol
• ICMP – Internet Control Message Protocol
• ARP – Address Resolution Protocol
• TLS – Transport Layer Security
• QUIC – (não é um acrônimo, mas inicialmente veio de Quick UDP Internet
Conections)
 • Multicast Domain Name Service (mDNS)
Primeiramente iremos falar sobre o que é DNS e Multicast, a fim de chegar em uma conclusão
do que é o Multicast DNS.
DNS, de forma resumida, é uma coleção de bancos de dados que traduz os nomes de host para
endereços únicos de IP. A busca de um site por exemplo... Cada site possui seu próprio
endereço de IP, e o DNS converte a URL do site em um endereço de IP a fim de fazer a
requisição no servidor.
Na figura 1 pode-se observar um teste feito no prompt de comando do Windows do site da
techtudo.com.br. Ao digitar o comando ping, + endereço do site, podemos obter o endereço IP
do site que estamos acessando.
É possível, de forma manual, definir qual provedor queremos utilizar para tal serviço. Por
padrão, utilizamos o serviço de DNS oferecido pelo provedor de acesso ou a empresa
responsável por manter a nossa conexão funcionando, como NET, Vivo e Oi, mas não é
obrigatório utilizá-lo.
A escolha de qual provedor escolher pode ser definido através dos pontos que melhor atendem a
necessidade, pode ser por segurança, velocidade, ou ambos, que é o caso de OpenDNS, Google
Public DNS e Comodo Secure DNS.

• Open DNS (servidores com IPS 208.67.222.222 e 208.67.220.220);

• Google DNS (servidores 8.8.8.8 e 8.8.4.4);
• Comodo DNS (servidores 8.26.56.26 e 8.20.247.20).
O Multicast, diferentemente do Unicast e Broadcast, é uma forma de troca de comunicação
através de grupos específicos, e que cada máquina tem sua assinatura, ou seja, são enviadas
informações para os grupos que tem tais assinaturas. Isso evita o envio das informações para
todos os hosts de forma desnecessária, como é o caso de Broadcast.
Logo, o método que utiliza uma semântica familiar de operação, formato de pacotes e interfaces
de DNS em redes pequenas é denominado de Multicast DNS. Cada dispositivo conectado na
rede há seu endereço DNS, e caso seja feita alguma requisição, apenas os grupos de mesmo
endereço que foi requisitado terão que responder. Todo nó com endereço de mDNS reservado é
enviado com pacotes IP e a resposta aos mesmos é fornecida com recursos de serviço por
dispositivos.
Quando um cliente mDNS precisa de buscar algum host, envia uma mensagem de
consulta multicast IP que pede ao host que tenha esse nome para se identificar. A máquina com
tal IP responde com uma mensagem em multicast que inclui seu endereço IP. Agora todas as
máquinas dessa sub-rede podem então utilizar essa informação para atualizar as suas caches
mDNS.
É chamado também de configuração zero, é um conjunto de tecnologias que cria
automaticamente uma rede de computador utilizável baseada na Suite de Protocolo
de Internet (TCP/IP) quando computadores ou periféricos de rede estão interligados.
O uso de mDNS pode ocasionar algumas vulnerabilidades. As informações do seu servidor
podem ser recolhidas por hackers quando o serviço é questionado em caso de exposição do seu
mDNS à Internet. Estas informações incluem endereço MAC do dispositivo, serviços que estão
a ser geridos na máquina etc. Então, o mDNS destina-se a ser utilizado dentro da rede local, a
exposição direta desse serviço deve ser evitada à Internet.
Figura 1
 • Simple Service Protocol (SSDP)
Basicamente, o Simple Service Protocol é um protocolo utilizado para descobrir máquinas
ligadas a mesma rede a qual está o protocolo. Está inserido no UPnP (Universal Plug and Play)
que possibilita que as máquinas e dispositivos ligados na mesma rede se comuniquem
automaticamente, em ambientes residenciais e pequenos escritórios.
O termo UPnP é derivado de “Ligar e Usar”, uma tecnologia de conexão dinâmica de
dispositivos a um computador. Universal Plug and Play é um conjunto de protocolos
de rede de computadores. As metas de UPnP são para conexão direta e simplificação da
implementação de redes em casa e em escritórios. A tecnologia "Ligar e Usar" é para ligação
direta entre um computador e um dispositivo.
Além disso, a tecnologia Universal Plug and Play é utilizado em jogos e streamings, pois ajuda
a facilitar a experiência com jogos online e streaming em geral. Ao invés de ter que configurar
tudo manualmente e decidir que portas devem ser abertas para permitir as conexões, a UPnP faz
todos estes procedimentos.
A comunicação atual entre máquinas e dispositivos, como: celulares, smartwatch, vídeo-games,
TV’s, são realizadas pelo UPnP, e o SSDP que reconhece estes dispositivos em uma mesma
rede. Porém, algumas cautelas devem ser consideradas para evitar invasões e ataques de
hackers, como até mesmo utilizar uma boa VPN profissional configurada diretamente no
roteador, pois permite proteger os dispositivos conectados.
O SSDP é um protocolo baseado em texto que é baseado em HTTPU. Ele usa UDP como
protocolo de transporte subjacente. Os serviços são anunciados pelo sistema de hospedagem
com endereçamento multicast para um endereço IP multicast, especificamente designado na
porta UDP de número 1900. Isso resulta nos seguintes endereços multicast práticos bem
conhecidos para SSDP:

• 239.255.255.250 (endereço local de site IPv4)

• [FF02 :: C] (link-local IPv6)
• [FF05 :: C] (site-local IPv6)
• [FF08 :: C] (organização IPv6 local)
• [FF0E :: C] (IPv6 global)

Alguns ataques de hacker podem ocorrer, como em 2014, que foi descoberto que o SSDP estava
sendo usado em ataques DDoS conhecidos como um ataque de reflexão SSDP com
amplificação. Isso ocorre, pois, muitos dispositivos, incluindo até mesmo alguns roteadores
residenciais, têm uma vulnerabilidade no software UPnP que possibilita e permite que o invasor
obtenha respostas da porta de número 1900 para um endereço de destino de sua escolha. É
possível também que os hackers gerem taxas de pacotes suficientes que ocupem a largura de
banda para saturar links, causando negações de serviços. A empresa de
rede Cloudflare descreveu este ataque como o "Protocolo DDoS estupidamente simples".
Uma vulnerabilidade foi encontrada também no FireFox para Android anteior à versão 79, pois
não validava corretamente o esquema do URL que era recebido no SSDP e era vulnerável à
execução remota de código. Isso acarreta que um invasor na mesma rede pode criar um servidor
malicioso fingindo ser um dispositivo de suporte à transmissão.
 • Internet Control Message Protocol (ICMP)
O protocolo ICMP é um padrão TCP/IP necessário, são feedbacks IETF que estabelecem os
padrões de cada protocolo com o ICMP, os hosts e roteadores que usam comunicação IP podem
relatar erros e trocar informações de status.
Logo, a principal utilização do Internet Control Message Protocol é fornecer
mensagens/relatórios de erros à fonte original. As mensagens ICMP são geralmente enviadas
em certas ocasiões, algumas delas:
1. Um pacote IP não consegue chegar ao seu destino (Tempo de vida do pacote expirado)
2. O Gateway não consegue retransmitir os pacotes na frequência adequada (Gateway
congestionado)
3. O Roteador ou Encaminhador indica uma rota melhor para a máquina a enviar pacotes.
O envio de mensagens de erro é totalmente necessário para o reconhecimento de erros ou até
mesmo de melhorias, resultando em uma melhor eficiência na entrega de pacotes.
Fazendo uma analogia, pode-se imaginar o ICMP como uma equipe em uma fábrica que está ali
para notificar qualquer erro ocorra em uma produção. Em uma fabricação de carros, por
exemplo, a melhor forma de montar um veículo seria fabricar primeiro cada peça individual
antes de enviar cada uma destas peças para a linha de montagem. No entanto, como todos
sabemos, haverá momentos em que o equipamento de produção não poderá enviar algumas das
peças num prazo determinado. Se alguma vez houver peças em falta, a linha de montagem terá
que notificar a equipe de produção, portanto, o ICMP funciona da mesma forma. Poderia até
mesmo ocasionar em algum acidente caso a informação não tivesse sido transmitida, como
também pararia toda a produção.
Com essa analogia percebe-se que o envio a comunicação pela troca de mensagens é
extremamente necessário. Logo, essencialmente, o ICMP desempenha o papel de mensageiro
que transmite dados e informações do destinatário para o remetente.
Além disso, este protocolo tem diversas outras funções, além de apenas relatar erros em
transmissões de pacotes e hosts que não podem ser alcançados. São responsáveis também por
retransmitir ecos, que é utilizado em um comando PING conhecido que permite aos usuários e
utilizadores a transmitirem um eco a um host.
Além disso, essas mensagens são bastante utilizadas para administradores poderem encontrar
erros de conexão enfim de solucioná-los.
A mensagem mais comum é a de “Destino Inalcançável”, porém há outras mensagens que
poderão ser vistas como:

• Redirecionar Mensagem – Isto é o que um gateway usa para que o host de origem saiba
que ele vai enviar tráfego para um roteador diferente.
• Time Exceeded – Isto é o que um roteador irá dizer à máquina fonte que um
determinado pacote excedeu um determinado período de tempo chamado Time to Live
(TTL). Quando um determinado host começa a receber os pacotes de informação “Time
Exceeded”, isto é um sinal de que há um problema dentro do sistema onde um loop de
feedback existe no fluxo de informação.
• Source Quench – São mensagens que são enviadas de um roteador para o host. Isto
deixa-o saber que a capacidade de amortecimento é agora cheia e parará brevemente o
processo de transmissão para que ele seja capaz de alcançar o resto dos dados.
• O servidor envia uma mensagem ao cliente e indica que sua próxima mensagem será
criptografada com a chave de sessão. Em seguida, ele envia uma mensagem separada
(criptografada) indicando que a parte do handshake do servidor foi concluída.
O handshake TSL / SSL é concluído e a sessão segura começa. O cliente e o servidor usam
a chave de sessão para criptografar e descriptografar os dados enviados um para o outro e
verificar a integridade. Se alguma das etapas acima falhar, o handshake e a conexão não
serão criados. Na etapa 3, o cliente deve verificar a cadeia de "assinatura" da "raiz de
confiança" embutida para o cliente. O cliente também deve verificar se nenhuma das
assinaturas foi revogada. Em muitas versões, essas assinaturas não são boas implementado,
mas é qualquer Os requisitos do sistema de autenticação de chave pública.
 • Address Resolution Protocol (ARP)
O Protocolo de Resolução de Endereços é um protocolo padrão da telecomunicação com o
objetivo de buscar endereços MAC para comunicação.
O protocolo ARP entra em operação com a fim de buscar o endereço MAC do host para se
comunicar com o respectivo endereço IP. Primeiramente é realizado um ARP request em
Broadcast (se comunica com todos os hosts), e ao encontrar o host com o respectivo endereço IP
que foi requisitado, este host retorna o endereço MAC por transmissão Unicast para quem
requisitou. Logo, as próximas requisições daquele IP serão por Unicast, exatamente pelo
computador já ter ciência de qual endereço buscar.
No prompt de comando, ao digitar arp -a tem-se a tabela arp:

Onde a coluna de endereço de IP (à esquerda) é o endereço da máquina, e o endereço físico é o

endereço MAC. A tabela ARP armazena o endereço físico, o lógico e o tipo de endereço lógico.
Já o Proxy ARP é uma variação do ARP, possibilita que uma organização possua somente um
endereço IP para suas diversas redes.
Nesse caso, todas as redes estão conectadas a um router. Quando um host quiser se comunicar
com um host de outra rede (sem saber seu endereço MAC), ele irá despejar um pacote com o
número IP do host destino. Mas nesse caso o pacote é interceptado primeiramente pelo router,
que retorna ao host destino seu próprio endereço MAC. A informação subseqüente será então
orientada para o router, que a redirecionará para o host destino, de acordo com a sua própria
tabela de endereços.
Para exemplificar melhor o funcionamento do protocolo ARP, imagine uma situação em que
estou buscando o endereço MAC da máquina host com endereço IP 3.1:
É realizado um Arp-Request. Logo em seguida o switch envia o request em BroadCast para os
hosts a fim de buscar a informação do endereço MAC...

E então o host com o IP 3.1 responde de volta para o switch com seu endereço MAC. Enviando
de volta para o computador.

Agora. As próximas requisições serão UniCast, exatamente pelo computador já saber para qual
host ele irá enviar informações, acelerando a comunicação, exatamente por evitar um novo
BroadCast, que forçaria um trabalho dos hosts indesejados desnecessariamente.
 • Transport Layer Security (TLS)
O Transport Layer Security é um protocolo de criptografia que habilita conexões autenticadas e
o transporte seguro de dados através da internet via HTTP. O SSL (Secure Sockets Layer) e seu
sucessor TLS (Transport Layer Security) permitem a comunicação segura entre os lados cliente
e servidor de uma aplicação web.
A maior vantagem desses protocolos é que eles atuam como uma subcamada do protocolo de
comunicação da Internet (TCP / IP). É aqui que reside a diferença entre HTTP e HTTPS. O
primeiro é para transações em texto simples e o segundo é criptografado por SSL / TLS. Ou
seja, você pode operar com ou sem TLS (ou SSL), e o cliente só precisa indicar ao servidor se
deseja configurar uma conexão segura. Existem duas maneiras principais de atingir esse
objetivo: uma é usar uma porta diferente para a conexão TLS, por exemplo, a porta TCP / 443
para HTTPS; a outra é usar a mesma porta e solicitação do cliente para o servidor Use
mecanismos específicos de protocolo para alterar a conexão para TLS, por exemplo,
STARTTLS para protocolos de e-mail como IMAP e POP3.
Depois que o cliente e o servidor decidem usar TLS / SSL, eles usam um processo de handshake
para negociar o status da conexão, durante o qual o cliente e o servidor concordam com vários
parâmetros para estabelecer uma conexão segura.

• O cliente envia ao servidor sua versão com TSL / SSL, configurações de criptografia,
dados específicos da sessão (ID da sessão) e outras informações exigidas pelo servidor
para se comunicar com o cliente usando SSL.
• O servidor envia sua versão TSL / SSL, configurações de criptografia, dados específicos
da sessão e outras informações que o cliente também precisa para o cliente. O servidor
também enviará seu próprio certificado e, se o recurso do servidor solicitado pelo
cliente exigir a autenticação do cliente, o servidor solicitará o certificado do cliente.
• O cliente utiliza as informações enviadas pelo servidor para autenticar o servidor, ou
seja, confirma que todas as configurações recebidas pelo servidor estão de acordo com o
esperado e, a seguir, continua a conexão segura. Caso contrário, a solicitação será
interrompida e o usuário será notificado.
• O cliente (usando a cooperação do servidor, dependendo da senha usada) usa todos os
dados gerados no handshake até o momento, cria um segredo pré-mestre para a sessão e
usa a chave pública do servidor (obtida da chave do servidor) para emparelhar Ele é
criptografado. O certificado é enviado na etapa 2) e, em seguida, a senha mestre
criptografada é enviada ao servidor.
• Se o servidor solicitou autenticação do cliente (opcional), o cliente também assinará
outro dado que é exclusivo para este handshake e é conhecido tanto pelo cliente quanto
pelo servidor. Nesse caso, o cliente enviará os dados assinados e seu certificado e a
senha mestre criptografada para o servidor.
• Se o servidor solicitou a autenticação do cliente, o servidor tentará autenticar o cliente.
Se o cliente não puder ser autenticado, a sessão será encerrada da mesma maneira que
na etapa 3. Se o cliente for autenticado com sucesso, o servidor usará sua chave privada
para descriptografar a senha mestra e, em seguida, realizará uma série de etapas (o
cliente também executa (da mesma senha mestra antes da senha) para gerar a senha
mestra.
• Tanto o cliente quanto o servidor devem usar a chave mestra para gerar a chave de
sessão, que é uma chave simétrica usada para criptografar e descriptografar as
informações trocadas durante a sessão TSL / SSL e para verificar sua integridade (ou
seja, para verificar o segredo ). Quaisquer alterações na chave). Dados entre a hora em
que os dados foram enviados e a hora de recepção por meio da conexão SSL).
• O cliente envia uma mensagem ao servidor, indicando que a próxima mensagem do
cliente será criptografada com a chave de sessão. Em seguida, ele envia uma mensagem
separada (criptografada) para indicar que o processo de handshake do cliente foi
concluído.
 • Protocolo QUIC
Basicamente, QUIC é um protocolo de rede de camada de transporte com propósitos gerais. E é
utilizado por mais da metade de todas as ligações do navegador Web Chrome.
O Google desenvolveu o QUIC (Quick UDP Internet Protocol), que veio com o objetivo de
poder manter a segurança e a velocidade das conexões HTTP consistentes. É a união entre o
melhor do TCP, que é a segurança; com o melhor do UDP, que é a velocidade. Mesmo em
conexões envolvendo o TLS.
Um esquema abaixo demostra a efetividade deste protocolo:

O tempo médio para o protocolo HTTP se conectar ao servidor é de 100 milissegundos.

Quando se trata do protocolo de segurança TLS, o tempo salta de 200 milissegundos para 300
milissegundos.
O tempo médio mais longo é quando o dispositivo se conecta ao servidor pela primeira vez.
Quando esta conexão é repetida, o tempo médio é menor.
Quando olhamos para o QUIC, percebemos que a conexão é transitória para conexões repetidas.
Mesmo com TLS, uma nova conexão leva 100 milissegundos.
O QUIC melhora o desempenho das aplicações web atuais orientadas a conexões que usam
TCP. Para tal, estabelece uma série de ligações multiplexadas entre os dois terminais do User
Datagram Protocol (UDP). Ele é usado com conexões de multiplexação HTTP / 2, permitindo
que vários fluxos de dados alcancem todos os pontos de extremidade de forma independente,
portanto, não tem nada a ver com a perda de pacotes envolvendo outros fluxos. Por outro lado,
se algum pacote TCP for atrasado ou perdido, o HTTP / 2 hospedado no Transmission Control
Protocol (TCP) pode sofrer um atraso de ponta a ponta.
No método acima, é óbvio que HTTP é a pessoa que envia as informações independentemente
da versão. Depois disso, temos um sistema para gerenciar todas essas funções de comunicação
de dados.
O gerenciador pode ser TCP (Transmission Control Protocol) ou UDP (User Datagram
Protocol). A garantia de segurança e agilidade está relacionada a esses dois softwares.
O TCP tem a vantagem de segurança. Isso garante que os pacotes de dados não sejam perdidos
no caminho entre o servidor do usuário e o dispositivo. Além do TLS, essa combinação também
é muito adequada para segurança.
Mas esse método atrapalha a velocidade. Nesse sentido, o UDP é mais recomendado porque
ignora o processo de verificação da integridade do pacote de informações transmitido.
Perceba que é impossível ajustar a velocidade com segurança usando essas técnicas. Todos nós
precisamos dele, e é por isso que QUIC e HTTP / 3 apareceram.
2. Para as transações na Internet são cruciais protocolos da camada 3 como RIP, OSPF,
BGP e outros. Inicie também aqui uma sessão de WireShark no seu computador de
trabalho em modo promíscuo durante um ou dois minutos (com ou sem uso
simultâneo do seu browser) e confirme que estes protocolos não aparecem lá. Qual a
razão de ser assim, de estes protocolos não aparecerem? Documente um trecho
qualquer de sua captura.
A camada 3 ocorre especificamente na rede, todos os envios de informações e o tratamento de
dados. Para nossa máquina pouco interessa sobre o processo que ocorre antes do pacote chegar,
o que importa de verdade é o dado que chega. Ou seja, esses protocolos não estão rodando na
máquina que estamos vendo o tráfego.
A visão do Wireshark é a visão da borda da rede, está pegando os pacotes de origem ou destino.
Sendo assim, conseguimos apenas observar os protocolos que rodam nas bordas. Como pode ser
observado nos prints posteriores, ao filtrar por alguns protocolos da camada 3, não temos
resultados.
Para o caso de querermos observar tais protocolos da camada 3 teríamos que realizar comandos
de ping ou até mesmo de traceroute.
Podemos ver alguns protocolos como: TCP, DNS e TLS. Que estão sendo processados na minha
rede.