Redes de Computadores

Transcrição

1 Prof. Universidade Federal de Mato Grosso do Sul 16 de maio de 2017

2 Visão Geral 1 Camada de Aplicação 2 3 4

3 Camada de Aplicação Ao analisar esta camada devemos focar em alguns objetivos: aspectos conceituais de implementação de protocolos de aplicação; modelo de serviços da camada de transporte; paradigma cliente-servidor; paradigma peer-to-peer (par a par). aprender sobre os principais protocolos que estão na camada de aplicação. DNS HTTP FTP SMTP / POP3 / IMAP

4 Aplicativos de Rede Algumas aplicações conhecidas: ; web; mensagens de texto; acesso remoto; compartilhamento de arquivos P2P; jogos em rede; streaming de vídeos (YouTube, Hulu, Netflix); voz sobre IP (ex.: Skype); conferência em tempo real; redes sociais; mecanismos de busca;...

5 Aplicação de Rede Escrever programas que: fucionem em (diferentes) sistemas finais. se comuniquem pela rede. ex.: navegadores de Internet. sem necessidade de escrever programas para os dispositivos do núcleo (core) da rede: dispositivos do core da rede não executam aplicações dos usuários. aplicações em sistemas finais permitem o rápido desenvolvimento e propagação.

6 Arquiteturas de Aplicações As aplicações podem seguir dois modelos estruturais: cliente-servidor; peer-to-peer (P2P).

7 Arquitetura Cliente-Servidor Servidor: sempre ligado endereço IP fixo hospedados em centros de dados para escalabilidade Clientes: comunicam com o servidor podem estar intermitentemente conectados podem ter endereços IP dinâmicos não se comunicam diretamente entre si

8 Arquitetura P2P servidor não precisa estar sempre ligado sistemas finais arbitrários podem se comunicar diretamente pares (peers) podem requisitar serviços de outros pares e fornecer serviço para outros. auto-escalabilidade: novos pares agregam mais capacidade ao serviço, assim como novas demandas por serviço. pares podem estar conectados de forma intermitente e também mudar seus endereços IP torna o gerenciamento complexo

9 Processo de Comunicação processos: programas executando em um host no mesmo host, dois processos se comunicam usando IPC (inter-process communication) definido pelo SO. processos em hosts diferentes se comunicam trocando mensagens. Cliente/Servidor: P2P: processo cliente: inicia a comunicação processo servidor: processo que espera ser contactado aplicações P2P são, ao mesmo tempo, processos cliente e servidor

10 Sockets processo envia/receve mensagens do/para o socket.

11 Endereçando Processos para receber mensagens, um processo precisa de um identificador dispositivos de rede tem um endereço IPv4 único de 32-bits e IPv6 de 128-bits Para que vários processos executem em um mesmo host precisamos de mais identificadores. identificadores incluem tanto o endereço IP quanto o número da porta associada ao processo no host. exemplo de números de portas: Servidor HTTP: 80 Serviço SMTP: 25 Ou seja, para enviar mensagens para usamos: Endereço IP: Número da Porta: 80

12 Definições da Camada de Aplicação tipos de mensagens trocadas. ex.: requsição e resposta sintaxe da mensagem: quais campos nas mensagens e como os campos são delineados semântica da mensagem: significado da informação no campo regras: para quando ou como os processos enviam e respondem as mensagens protocolos abertos: definido pelas RFCs permite interoperabilidade ex.: HTTP, SMTP, etc. protocolos proprietários: ex.: Skype

13 Serviço de Transporte para Aplicações integridade dos dados: algumas aplicações (ex.: transferencia de arquivos, transferências web) precisam que os dados sejam transferidos de forma 100% confiável. outros aplicativos (ex.: audio) podem tolerar alguma perda. temporização: algumas aplicações (ex.: Telefonia na Internet, jogos interativos) precisam de um atraso baixo para ser efetivo. vazão: alguns aplicativos (ex.: multimídia) precisam de uma quantidade de throughput mínima para ser efetivo. outros aplicativos ( aplicativos elásticos ) podem usar qualquer vazão que você possua. segurança: encriptação, integridade dos dados, etc.

14 Protocolos de Transporte TCP: Transporte confiável: entre o processo emissor e receptor Controle de fluxo: o emissor não sobrecarrega o servidor Controle de congestionamento: ajusta o emissor quando a rede esta sobrecarregada Não fornece: temporização, garantia de vazão mínima, segurança Orientado a conexão: configuração inicial é necessária entre o cliente e o servidor UDP: Transferência não confiável: entre o emissor e o receptor Não fornece: confiabilidade, controle de fluxo, controle de congestionamento, temporização, vazão garantida, segurança ou configuração de conexão. Pergunta: Por que ainda nos importamos com o UDP?

15 DNS - Domain Name System

16 Domain Name System Pessoas: vários identificadores. ex.: identidade, CPF, passaporte. Hosts de Internet, roteadores: Endereço IP (32 bits - usado para endereçar datagramas). nome, ex.: usado por humanos. Pergunta: Como mapear endereços IP e nomes ou vice e versa? DNS (Domain Name System): Base de dados distribuída implementada em uma hierarquia com vários servidores de nomes. Protocolo na camada de aplicação: hosts, servidores de nomes se comunicam para resolver nomes (endereços/nome traduzido). nota: função do núcleo da Internet, implementada na camada de aplicação. complexidade fica nas bordas da rede.

17 DNS: serviços, estrutura Serviços do DNS: Tradução de nome para endereço IP. Alias de host canonico, alias de nomes alias de servidor de distribuição de carga Servidores Web Replicados: vários endereços IP correspondem a um único nome. Por que não centralizar o DNS? único ponto de falha volume de tráfego distância da base centralizada manutenção Resposta: não escala!

18 Hierarquia dos Servidores DNS A estrutura de tradução dos servidores de nomes é muito similar a uma árvore e confia em sua natureza distribuída para garantir escalabilidade.

19 DNS: servidores de nome raízes A estrutura de tradução dos servidores de nomes é muito similar a uma árvore e confia em sua natureza distribuída para garantir escalabilidade.

20 DNS: exemplo de resolução de nome (iterativo) 1 Cliente requisita DNS Local (cis.poly.edu) 2 DNS Local (cache miss) envia requisição aos DNS Root 3 Resposta do DNS Root 4 DNS Local consulta DNS TLD (Top-Level Domain) 5 Resposta do DNS TLD 6 DNS Local consulta DNS Autoritário do domínio 7 Resposta do DNS Autoritário 8 DNS Local responde ao Cliente

21 DNS: exemplo de resolução de nome (recursivo) 1 Cliente requisita DNS Local (cis.poly.edu) 2 DNS Local (cache miss) envia requisição aos DNS Root 3 DNS Root requisita DNS TLD 4 DNS TLD consulta DNS Autoritário 5 Resposta ao DNS TLD 6 Resposta ao DNS Root 7 Resposta ao DNS Local 8 DNS Local responde ao Cliente

22 DNS: comparação de consultas No modo iterativo de consulta: O servidor contactado responde com o nome do próximo servidor a ser contactado até descobrir o DNS responsável pela zona. Eu não sei este nome, mas pergunte a este outro servidor No modo recursivo de consulta: Coloca o peso da consulta ao servidor de nomes contactado. Alta carga de trabalho para os níveis mais altos da hierarquia.

23 DNS: cache e atualização de registros Uma vez que (qualquer) servidor de nomes aprenda um mapeamento, ele faz cache deste mapeamento. até que a validade de tempo do cache expire (TTL) Servidores DNS TLD fazem, normalmente, cache local logo, servidores raízes são pouco visitados Entradas em cache podem estar desatualizadas (tradução de nomes no melhor esforço!) Se um endereço IP relacionado a um nome mudar, ele não será conhecido até que todos os TTL s na Internet expirem. Mecanismo de atualização/notificação proposto pela IETF na RFC 2136

24 DNS: entradas As entradas do DNS possuem armazenamento distribuído de entradas (RR - Resource Records): Formato RR: (name, value, type, ttl) type=a: name é o nome do host value é o endereço IP type=ns: name é domínio value é nome do host autoritário a este domínio type=cname: name é um alias para algum nome canônico (nome real) value é o nome canônico type=mx value é o nome do servidor de associado ao name

25 DNS: protocolo e mensagens mensagens de consulta e resposta tem o mesmo fomato de mensagem. cabeçalho da mensagem: identification: 16 bits para consultas, respostas flags: consulta ou resposta recursão desejada recursão disponível resposta é autoritária

26 DNS: protocolo e mensagens questions: nome, campo de tipo de uma consulta answers: RR s em resposta a uma consulta authority: entradas para autoridade additional info: entradas úteis que podem ser usadas

27 DNS: exemplo de DNS autoritário O software de DNS mais utilizado é o Bind em sua versão 9. Observem a estrutura do arquivo da Zona de nomes da FACOM. O Bind 1 é desenvolvido pela Internet Systems Consortium. 1

28 Atacando o DNS Ataques DDoS: Bombardear os servidores root com tráfego Não foram bem sucedidos até agora Filtro de tráfego Servidores Locais e TLD fazem cache evitando o acesso aos servidores root Bombardear os servidores TLD (Potencialmente mais perigoso) Redirecionamento de ataques: Man-in-middle: intercepta consultas DNS poisoning: envia informações erradas ao servidor DNS para que ele faça cache Explorar o DNS para DDoS: Envia consultas com a origem modificada para o IP destino

29 de Consulta a Nomes Duas ferramentas muito utilizadas na tradução de nomes são: dig nslookup

30 Percorrendo o caminho da consulta 1 O processo começa a tradução pelos servidores raízes e continua, consumindo o nome requisitado de trás para frente até alcançar os servidores de nomes responsáveis pela zona desejada; 2 Em seguida, a requisição é analisada e o subdomínio desejado consultado; 3 Notem que o domínio fornece dois servidores de DNS para a mesma zona.

31 Consultando um nome com dig ;; QUESTION SECTION: ; IN A ;; ANSWER SECTION: IN A ;; Query time: 109 msec ;; SERVER: #53( )

32 -t mx gmail.com ;; QUESTION SECTION: ;gmail.com. IN MX ;; ANSWER SECTION: gmail.com IN MX 20 alt2.gmail-smtp-in.l.google.com. gmail.com IN MX 10 alt1.gmail-smtp-in.l.google.com. gmail.com IN MX 5 gmail-smtp-in.l.google.com. gmail.com IN MX 30 alt3.gmail-smtp-in.l.google.com. gmail.com IN MX 40 alt4.gmail-smtp-in.l.google.com. ;; Query time: 76 msec ;; SERVER: #53( )

33 -t mx gmail.com ;; QUESTION SECTION: ;gmail.com. IN MX ;; ANSWER SECTION: gmail.com IN MX 30 alt3.gmail-smtp-in.l.google.com. gmail.com IN MX 20 alt2.gmail-smtp-in.l.google.com. gmail.com IN MX 10 alt1.gmail-smtp-in.l.google.com. gmail.com IN MX 40 alt4.gmail-smtp-in.l.google.com. gmail.com IN MX 5 gmail-smtp-in.l.google.com. ;; Query time: 81 msec ;; SERVER: #53( )

34 : motivação Se você enviar uma consulta e receber uma resposta, como é possível confiar na resposta? qualquer um que conseguir interceptar a consulta pode me enviar uma resposta arbitrária. ex.: um ISP deseja me redirecionar mesmo sem interceptar uma consulta, um atacante pode adivinhar uma consulta e seu identificador O DNS não é seguro: a resposta pode me retornar um endereço IP errado.

35 : estratégia O cliente e o resolvedor devem conhecer uma chave raiz. Essa chave raiz é usada para assinar a chave do TLD. A chave do TLD é usada para assinar uma chave menor e assim sucessivamente. o cliente que recebe uma consulta segue a cadeia de assinaturas até chegar a chave raiz. Isso confirma que o RR recebido foi assinado por alguém conhecido pelo nível superior voltando ao DNS root.

36 : fraquezas O não está totalmente difundido. logo, respostas não autenticadas podem ser legítimas. O cliente e o resolvedor precisam conhecer a chave raiz. O releva os dados da zona. o que diversos administradores preferem manter em segredo. fornece autenticação, mas não confidencialidade. O DNS é muito mais leve que o.

37 Perguntas?