Curso Técnico Integrado de Telecomunicações - Redes de Computadores (RCO)

MURAL DE AVISOS E OPORTUNIDADES DA ÁREA DE TELECOMUNICAÇÕES

Informações Gerais

• Carga horária, Ementas, Bibliografia
• Plano de Ensino
• Cronograma de atividades

Edições

• RCO60803 2017-2 - Prof. Odilson Tadeu Valle / Prof. Eraldo Silveira e Silva
• RCO60803 2017-1 - Prof. Juliano de Souza / Prof. Eraldo Silveira e Silva
• RCO60803 2016-2 - Prof. Juliano de Souza / Prof. Luciano Barreto
• RCO60803 2016-1 - Prof. Fernando Rodrigues Santos / Prof. Juliano de Souza
• RCO60803 2015-2 - Prof. Simara Sonaglio
• RCO60803 2015-1 - Prof. Arliones Hoeller / Prof. Túlio Ribeiro
• RCO60803 2014-2 - Prof. Arliones Hoeller / Prof. Tomás Grimm / Prof. José Clair

Laboratórios

Laboratório 1 - Ferramentas de Rede e Conceitos Básicos

Objetivos Familiarização com a infraestrutura dos laboratórios de redes, incluindo as máquinas virtuais Virtualbox Familiarização com ferramentas de rede: ifconfig, ping, traceroute; Desenvolver a noção de endereçamentos de rede IP e de endereço de hardware (MAC) Desenvolver a noção de rotas em redes IP testar a conectividade IP com ping Conceitos introdutórios para uso do laboratório Estrutura do Laboratório A rede do laboratório em uso segue o modelo apresentado no diagrama da Figura 1 (endereçamento pode ser diferente). Figura 1 - Diagrama da rede do laboratório Os Laboratórios de Redes de Computadores estão equipados com N+1 (N = número de computadores para alunos) computadores conectados em rede e com acesso a Internet, Figura 1. A rede local do laboratório tem endereço IP 192.168.1.0/24. A máscara de rede /24 indica que o último byte do endereço é utilizado para identificar cada máquina, por exemplo 192.168.1.1, 192.168.1.2, etc. Máquinas virtuais O sistema operacional hospedeiro é o Linux Ubuntu. Como os laboratórios são utilizados por várias disciplinas/alunos/professores, os usuários não tem acesso a senha de root (administrador). Para possibilitar a execução de comandos exclusivos do administrador (usuário root), cada computador tem instaladas máquinas virtuais, as quais podem ser lançadas a partir do aplicativo VirtualBox. As máquinas virtuais pertencem a mesma rede local do laboratório e tem endereçamento 192.168.1.x, sendo o byte que identifica a máquina (x) deverá ser manualmente configurado com a seguinte regra: M1 – 101, M2 – 102,..., M9 – 109, M10 – 110,..., M14 – 114 . Por exemplo:, M1 ficará com o endereço 192.168.1.101. Roteiro de atividades

thumb Parte 1: Observando interfaces do sistema com ifconfig O aplicativo ifconfig pode ser utilizado para visualizar a configuração ou configurar uma interface de host em redes TCP/IP. Se nenhum argumento for passado na chamada do ifconfig, o comando mostra a configuração atual de cada interface de rede. Consultar as páginas man ifconfig do Linux para maiores detalhes sobre o funcionamento deste aplicativo, o qual permite ativar/desativar a interface, configurar o endereço IP, definir o tamanho da MTU, redefinir o endereço de hardware se a interface suporta, redefinir a interrupção utilizada pelo dispositivo, entre outros. Analisando os dados obtidos do seguinte exemplo ifconfig eth0 Link encap:Ethernet Endereço de HW 64:51:06:1a:f3:da inet end.: 172.18.18.14 Bcast:172.18.63.255 Masc:255.255.192.0 endereço inet6: fe80::6651:6ff:fe1a:f3da/64 Escopo:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Métrica:1 pacotes RX:415237 erros:0 descartados:0 excesso:0 quadro:0 Pacotes TX:118109 erros:0 descartados:0 excesso:0 portadora:0 colisões:0 txqueuelen:1000 RX bytes:364658695 (364.6 MB) TX bytes:18315199 (18.3 MB) IRQ:18 lo Link encap:Loopback Local inet end.: 127.0.0.1 Masc:255.0.0.0 endereço inet6: ::1/128 Escopo:Máquina UP LOOPBACK RUNNING MTU:65536 Métrica:1 pacotes RX:6688 erros:0 descartados:0 excesso:0 quadro:0 Pacotes TX:6688 erros:0 descartados:0 excesso:0 portadora:0 colisões:0 txqueuelen:0 RX bytes:1057934 (1.0 MB) TX bytes:1057934 (1.0 MB) </syntaxhighlight> O sistema em questão possui duas interfaces de rede: eth0 e lo Link encap:Ethernet: Configuração da interface Ethernet 0 (primeira) Endereço de HW 64:51:06:1a:f3:da: É o endereço da placa de rede, camada 2 inet end.: 172.18.18.14 Bcast:172.18.63.255 Masc:255.255.192.0: Endereço IPv4 associado a interface, seu respectivo endereço de broadcast e mascara de rede endereço inet6: fe80::6651:6ff:fe1a:f3da/64 Escopo:Link: Endereço IPv6 de escopo local gerado por autoconfiguração UP BROADCAST RUNNING MULTICAST: Significa que a interface está ativa (UP), responde a requisições de broadcast (pode ser desabilitado no kernel) e também pode ser associada a tráfegos multicast MTU: 1500: Maximum Transfer Unit – Tamanho máximo do pacote suportado pelo enlace que é do tipo Ethernet Os demais parâmetros são estatísticas da respectiva interface, como por exemplo, pacotes transmitidos, recebidos etc A interface lo: Qualquer tráfego que um computador envie em uma rede loopback é endereçada ao mesmo computador. O endereço IP mais usado para tal finalidade é 127.0.0.1 no IPv4 e ::1 no IPv6. O nome de domínio padrão para tal endereço é localhost. Em sistemas Unix, a interface loopback é geralmente chamada de lo ou lo0. Agora utilize o comando ifconfig para verificar o estado de suas interfaces e responda: Quantas e quais interfaces de rede sua máquina possui? Liste. Quais são os endereços da camada 2 atribuído as mesmas? De onde o sistema obteve esses endereços? Quais são os endereços IPv4? De onde o sistema obteve esses endereços? Suas interfaces tem IPv6 configurado? Qual o endereço e escopo dos mesmos? Como foram obtidos? Qual o alcance (é roteável) do mesmo? Use o link *Verificando a estrutura do endereço IP para explorar a estrutura do seu endereço IPv4. Parte 2: Testando a conectividade com o ping Aplicativo ping permite a um usuário verificar se um host remoto está ativo. É bastante utilizado para detectar problemas de comunicação na rede. O ping está baseado no envio de mensagens de solicitação de eco (echo request) e de resposta de eco (echo reply). Estas mensagens fazem parte do rol de mensagens do protocolo ICMP, que é um protocolo de reportagem de erros, a ser estudado mais tarde, componente do protocolo IP. O ping é um dos principais comandos a disposição do administrador de rede no sentido de verificar a conectividade em rede. Por exemplo, se houver resposta de um ping a partir de um servidor remoto, significa que a máquina local está rodando corretamente o TCP/IP, o enlace local está funcionando corretamente, o roteamento entre a origem e o destino está operando, e por fim, a máquina remota também está rodando corretamente o TCP/IP. Consultar as páginas man do ping para verificar as possibilidades de uso deste aplicativo. Exemplo 1: PING 200.135.37.65 (200.135.37.65) 56(84) bytes of data. 64 bytes from 200.135.37.65: icmp_seq=1 ttl=62 time=0.925 ms 64 bytes from 200.135.37.65: icmp_seq=2 ttl=62 time=0.743 ms 64 bytes from 200.135.37.65: icmp_seq=3 ttl=62 time=0.687 ms 64 bytes from 200.135.37.65: icmp_seq=4 ttl=62 time=0.689 ms ^C --- 200.135.37.65 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 2999ms rtt min/avg/max/mdev = 0.687/0.761/0.925/0.097 ms </syntaxhighlight> No exemplo foram enviados quatro pacotes ICMP, cada um com um número de seqüência (icmp_seq), os quais foram recebidos com sucesso com o tempo de viagem assinalado (time) Cada pacote tem ainda um tempo de vida (ttl – time to live), o qual é decrementado em cada roteador, sendo o pacote descartado quando chegar a zero; isto evita pacotes perdidos na rede Quando o ping é interrompido (CRTL-C), uma estatística é apresentada indicando o percentual de pacotes transmitidos, recebidos e perdidos O tempo de viagem (rtt – round trip time) mínimo (min), médio (avg) e máximo (max) é calculado, assim como o desvio padrão (mdev) Como exercício envie ping para diferentes hosts e compare os tempos de resposta: no endereço local de loopback; máquina de um colega do laboratório; servidor e roteador da rede da escola; servidores externos: www.ifsc.edu.br www.uol.com.br www.nasa.com www.polito.it </syntaxhighlight> e explique as possíveis diferenças entre os tempos de resposta dos ping realizados. Consulte as páginas man e teste o ping com os parâmetros abaixo e descreva suas funcionalidades: -c count -i intervalo -s packetsize -t ttl (para um site distante inicie com 1 e vá incrementando, observe as mensagens) Observe que também é possível realizar ping em endereços no formato IPv6, por exemplo: ping6 www.sj.ifsc.edu.br </syntaxhighlight> Tente o ping6 para outros sites. Parte 3: Verificando rotas com o traceroute O traceroute é capaz de traçar uma rota aproximada entre dois hosts. Este comando usa mensagens ICMP. Para determinar o nome e o endereço dos roteadores entre a fonte e o destino, o traceroute na fonte envia uma série de datagramas IP ordinários ao destino. O primeiro datagrama tem o TTL (time to live – tempo de vida) igual a 1, o segundo 2, o terceiro 3, e assim por diante, e inicia temporizadores para cada datagrama. Quando o enésimo datagrama chega ao enésimo roteador, este verifica que o tempo de sobrevida do datagrama acaba de terminar. Pelas regras do IP, o datagrama é então descartado e uma mensagem ICMP de advertência tempo de vida excedido é enviada a fonte com o nome do roteador e seu endereço IP. Quando a resposta chega de volta a fonte, a mesma calcula o tempo de viagem em função dos temporizadores. O traceroute envia datagramas IP encapsulados em segmentos UDP a um host destino. Todavia escolhe um número de porta destino com um valor desconhecido (maior que 30000), tornando improvável que o host destino esteja usando esta porta. Quando o datagrama chega ao destino uma mensagem ICMP porta inalcançável é gerada e enviada a origem. O programa traceroute precisa saber diferenciar as mensagens ICMP recebidas – tempo excedido e porta inalcançável – para saber quando a rota foi concluída. Exemplo: traceroute 200.135.37.65 traceroute to 200.135.37.65 (200.135.37.65), 30 hops max, 60 byte packets 1 192.168.1.1 (192.168.1.1) 0.225 ms 0.216 ms 0.368 ms 2 172.18.0.254 (172.18.0.254) 1.236 ms 1.235 ms 1.343 ms 3 hendrix.sj.ifsc.edu.br (200.135.37.65) 1.331 ms 1.313 ms 1.414 ms </syntaxhighlight> O exemplo mostra a rota dos pacotes entre um computador do Lab. Redes (192.168.2.1) e o servidor hendrix (200.135.37.65). Observe que para cada roteador são realizados três amostras de tempo de ida e volta. Veja pelo mapa da rede do Campus São José que entre estes dois computadores, sistemas finais, existem dois roteadores intermediários, máquina do professor e Switch camada 3 (VLANs). Traçar a rota dos pacotes entre seu computador e diferentes hosts: máquina de um colega do laboratório servidor e roteador da rede da escola servidores externos. Explique as possíveis diferenças entre os tempos de resposta de cada uma das amostras do traceroute Explique as linhas com o caracter *. Fazendo uso das ferramentas desse laboratório, refaça o diagrama da rede do campus apontando claramente os novos endereços IPs associados aos roteadores. Observe que também é possível realizar traceroute em endereços no formato IPv6, por exemplo: traceroute -6 www.ufsc.br </syntaxhighlight> Tente o traceroute no IPv6 para outros sites. Referências adcionais [http://linux-ip.net/html Guia de Administração da Camada IP no Linux

Laboratório 2 - Wireshark, conceito de protocolo, encapsulamento

Objetivos Familiarização com o sniffer de rede WireShark Desenvoler o conceito de protocolo e encapsulamento WireShark 2005 KUROSE, J.F & ROSS, K. W. Todos os direitos reservados Introdução O entendimento de protocolos de redes pode ser bastante aprofundado através da “observação de protocolos funcionando” e “da manipulação de protocolos” - observando a sequência de mensagens trocadas entre duas entidades, entrando nos detalhes da operação do protocolo, e fazendo com que os protocolos realizem certas ações e então observando estas ações e as consequências. A ferramenta básica para observar as mensagens trocadas entre as entidades em execução é chamada de sniffer. Como o nome sugere, um sniffer captura mensagens sendo enviadas/recebidas pelo seu computador; ele também tipicamente armazena e/ou apresenta os conteúdos dos vários campos dos protocolos nestas mensagens capturadas. Um sniffer isoladamente é um elemento passivo. Ele observa as mensagens sendo enviadas e recebidas pelas aplicações e protocolos executando no seu computador, mas jamais envia pacotes. Similarmente, os pacotes recebidos nunca são explicitamente endereçados ao sniffer. Ao invés disso, um sniffer recebe uma cópia de pacotes que são enviados/recebidos para/de aplicações e protocolos executando no seu computador. A Figura 2 mostra a estrutura de um sniffer. À direita da Figura 2 estão os protocolos (neste caso, protocolos da Internet) e aplicações (tais como navegador web ou cliente FTP) que normalmente executam no seu computador. O sniffer, exibido dentro do retângulo tracejado na Figura 2 é uma adição aos softwares usuais no seu computador, e consiste de duas partes: a biblioteca de captura de pacotes e o analisador de pacotes. A biblioteca de captura de pacotes recebe uma cópia de cada quadro da camada de enlace que é enviado do ou recebido pelo seu computador. Lembre que mensagens trocadas por protocolos das camadas mais altas tais como HTTP, FTP, TCP, UDP, DNS ou IP, são todos eventualmente encapsulados em quadros que são transmitidos para o meio físico como um cabo Ethernet. Na Figura 2, assume-se que o meio físico é uma Ethernet, e desta forma, os protocolos das camadas superiores são eventualmente encapsulados em um quadro Ethernet. Capturar todos os quadros fornece todas as mensagens enviadas/recebidas de/por todos os protocolos e aplicações executando em seu computador. Figura 2 - Estrutura de um sniffer O analisador de pacotes exibe os conteúdos de todos os campos dentro de uma mensagem de protocolo. Para que isso seja feito, o analisador de pacotes deve “entender” a estrutura de todas as mensagens trocadas pelos protocolos. Por exemplo, suponha que estamos interessados em mostrar os vários campos nas mensagens trocadas pelo protocolo HTTP na Figura 5. O analisador de pacotes entende o formato dos quadros Ethernet, e desta forma pode identificar o datagrama IP dentro de um quadro. Ele também entende o formato do datagrama IP, para que ele possa extrair o segmento TCP dentro do datagrama IP. Ele entende a estrutura do segmento TCP, para que possa extrair a mensagem HTTP contida no segmento. Finalmente, ele entende o protocolo HTTP e então, por exemplo, sabe que os primeiros bytes de uma mensagem HTTP contém a cadeia “GET”, “POST” ou “HEAD”. Nós utilizaremos o sniffer Wireshark (http://www.wireshark.org) para estes laboratórios, o que nos permite exibir os conteúdos das mensagens sendo enviadas/recebidas de/por protocolos em diferentes camadas da pilha de protocolos. Tecnicamente falando, Wireshark é um analisador de pacotes que pode ser executado em computadores com Windows, Linux/UNIX e MAC. É um analisador de pacotes ideal para nossos laboratórios, pois é estável, tem uma grande base de usuários e é bem documentado incluindo um guia de usuário (http://www.wireshark.org/docs/wsug_html/), páginas de manual (http://www.wireshark.org/docs/man-pages/), e uma seção de FAQ detalhada (http://www.wireshark.org/faq.html), funcionalidade rica que inclui a capacidade de analisar mais que 500 protocolos, e uma interface com o usuário bem projetada. Ele funciona em computadores ligados a uma Ethernet para conectar-se à Internet, bem como protocolos ponto a ponto, tal como PPP. Analisando os campos da interface do Wireshark Quando você executar o programa Wireshark, a interface com o usuário exibida na Figura 3 aparecerá. Inicialmente, nenhum dado será apresentado nas janelas. A interface do Wireshark tem seis componentes principais: Os menus de comandos são localizados no topo da janela. Por enquanto, interessam apenas os menus File e Capture. O menu File permite salvar dados de capturas de pacotes ou abrir um arquivo contendo dados de capturas de pacotes previamente realizadas, e sair da aplicação. O menu Capture permite iniciar uma captura de pacotes; A barra de ferramentas contém os comandos de menu que são mais frequentemente utilizados. Há atalhos para abrir ou salvar dados de captura de pacotes e para iniciar ou parar uma captura de pacotes; Abaixo da barra de ferramentas, está o campo de filtragem de pacotes exibidos. Nele podem ser digitados nome de protocolo ou outra informação apresentada na janela de listagem de pacotes. Apenas os pacotes que correspondem ao filtro são exibidos; A janela de listagem de pacotes apresenta um resumo de uma linha para cada pacote capturado, incluindo o número do pacote (atribuído pelo Wireshark; este não é o número do pacote contido no cabeçalho de qualquer protocolo), o tempo que o pacote foi capturado, os endereços fonte e destino do pacote, o tipo de protocolo, e informação específica do protocolo contida no pacote. A lista de pacotes pode ser ordenada conforme qualquer uma destas categorias clicando no nome de uma coluna correspondente. O campo tipo do protocolo lista o protocolo de mais alto nível que enviou ou recebeu este pacote, i.e., o protocolo que é a fonte ou o último sorvedouro para este pacote; A janela de detalhes de cabeçalho de pacotes fornece detalhes sobre o pacote selecionado na janela de listagem de pacotes. Para selecionar um pacote, basta clicar sobre ele com o botão esquerdo do mouse na janela de listagem de pacotes. Os detalhes apresentados incluem informações sobre o quadro Ethernet e o datagrama IP que contém o pacote. A quantidade de detalhes exibida pode ser expandida ou contraída. Se o pacote foi carregado sobre TCP ou UDP, detalhes correspondentes também são apresentados, os quais também podem ser contraídos ou expandidos. Finalmente, detalhes sobre o protocolo de mais alto nível que enviou ou recebeu este pacote também são apresentados; A janela de conteúdo de pacotes mostra o conteúdo inteiro do quadro capturado, nos formatos ASCII e hexadecimal. Figura 3 - Interface com o usuário do Wireshark Roteiro de atividades Inicie o navegador web; Inicie o Wireshark. Inicialmente as janelas estarão vazias, pois não há captura de pacotes em progresso; Para iniciar uma captura de pacotes, selecione o menu Capture e depois Interfaces. Isso faz com que a janela de interfaces de rede disponíveis seja apresentada (Figura 4); Figura 4 - Interfaces de rede no Wireshark Basta clicar no botão Start da interface desejada para iniciar a captura de pacotes. Na Figura 4, como o Wireshark está sendo executado no Linux, o botão Start da interface eth0 deve ser selecionado; Como nada está acontecendo na rede, a janela apresenta o conteúdo vazio; No navegador, acesse o site http://www.ifsc.edu.br; Ao voltar para a janela do Wireshark, houve a captura de todos os pacotes envolvidos na conexão; Antes de continuar, vamos parar a captura de pacotes e trabalhar com o que temos. Basta clicar em Capture e depois em Stop; Para testar as capacidades de filtragem, vamos inserir a cadeia “http” (sem as aspas e em minúsculo) no especificação do filtro de exibição e depois selecionar Apply (ou Aplicar). Um resultado similar é exibido na figura 5; Figura 5 - Janela após a aplicação do filtro http Selecione a primeira mensagem HTTP exibida na janela de listagem de pacotes. Ela deve ser a mensagem HTTP GET que foi enviada do seu computador ao servidor HTTP em www.ifsc.edu.br. Quando você seleciona a mensagem HTTP GET, as informações dos cabeçalhos do quadro Ethernet, do datagrama IP, do segmento TCP e da mensagem HTTP aparecem na janela de cabeçalhos de pacotes. É possível ver os detalhes, expandido ou comprimindo os itens com um clique na seta ao lado deles. Se desejar acesse novos sítios e faça novas capturas e tente entender o que ocorre; Saia do Wireshark. Com Wireshark ativo (Abra-o novamente) acesse um sítio e responda às seguintes questões: Teste outros filtros, por exemplo, mostre somente pacotes originados e/ou destinados a um determinado host (ip.addr == 192.168...). Anote o filtro utilizado e salve a janela do mesmo. Elimine o filtro e anote os diferentes protocolos que aparecem na coluna Protocol na janela de listagem de pacotes; Quanto tempo passa entre o envio de uma mensagem HTTP GET até o recebimento de uma resposta OK? (por padrão, o valor da coluna Time na janela de listagem de pacotes é a quantidade de tempo, em segundos, desde que a captura iniciou). Para exibir o campo Time no formato hora do dia, selecione o menu View, depois Time Display Format, então selecione Time of day. Qual é o endereço IP do sítio navegado? Qual é o endereço IP da interface de rede do seu computador? Qual o endereço MAC de sua máquina? Roteiro de Atividades II Conceber um protocolo/serviço de calculadora pela rede. Todos grupos serão clientes e servidores de serviço. A estrutura básica de um pacote que flui do cliente para o servidor é: Tabela ASCII Ferramenta para conversão ASCII <==> Hexadecimal

Laboratório 3 - Desvendando o HTTP com Wireshark - BÁSICO

Fonte base: Wireshark - HTTP Objetivos Baseado na pequena introdução ao Wireshark apresentada no Laboratório 2, agora estamos prontos para utilizar o Wireshark para investigar protocolos em operação. Explorar vários aspectos do protocolo HTTP: a interação básica GET/resposta do HTTP, formatos de mensagens HTTP; diferenças http 1.0 e 1.1 / persistência PARTE 1 - Interação Básica GET/Resposta do HTTP Vamos iniciar a nossa exploração do HTTP baixando um arquivo em HTML simples - bastante pequeno, que não contém objetos incluídos. Faça o seguinte: inicie o navegador; limpe o cache do mesmo (teclas de atalho para o Firefox: Ctrl + Shift + Del); inicie o Wireshark, como descrito no Laboratório 1; inicie a captura de pacotes; digite o seguinte URL no navegador http://tele.sj.ifsc.edu.br/~odilson/RED29004//RED29004.html; pare a captura de pacotes; digite “http” (somente as letras, sem as aspas) na caixa de texto de especificação do filtro de exibição, de tal forma que apenas as mensagens HTTP capturadas serão exibidas na janela de listagem de pacotes. (Só estamos interessados em HTTP desta vez, e não desejamos ver todos os pacotes capturados). No browser, clique o botão da direita e visualize o código fonte da página adquyirida em html. Fig.1 Requisição e Resposta HTTP O exemplo da figura 1 mostra na janela de listagem de pacotes duas mensagens HTTP capturadas: A mensagem GET (do seu navegador para o servidor web www.sj.ifsc.edu.br) e a mensagem de resposta do servidor para o seu navegador. A janela de conteúdos de pacotes mostra detalhes da mensagem selecionada (neste caso a mensagem HTTP GET /~odilson/RED29004//RED29004.html, que está em destaque na janela de listagem de pacotes). A mensagem HTTP transportada em um segmento TCP, que é carregado em um datagrama IP, que é levado em um quadro Ethernet com 5728 bits no fio. Isso é observado de baixo para cima na janela de detalhes do cabeçalho do pacote selecionado. O Wireshark exibe informações sobre o quadro, IP, TCP e HTTP. Você deve expandir as informações, por exemplo, do HTTP clicando na seta ao lado esquerdo de “Hypertext Transfer Protocol”. Observando as informações das mensagens HTTP GET e de resposta. Você consegue inclusive enxergar a mensagem mostrada no navegador: RED29004! Página de teste. Responda às seguintes perguntas e imprima as mensagens GET e a resposta e indique em que parte da mensagem você encontrou a informação que responde às questões. O seu navegador executa HTTP 1.0 ou 1.1? Qual a versão de HTTP do servidor? Quais idiomas (se algum) o seu navegador indica ao servidor que pode aceitar? Qual o endereço IP do seu computador? E do servidor tele.sj.ifsc.edu.br? Qual o número da porta utilizada no seu computador? E do servidor tele.sj.ifsc.edu.br? Qual o código de status retornado do servidor para o seu navegador? Quando o arquivo em HTML que você baixou foi modificado no servidor pela última vez? Quantos bytes de conteúdo são baixados pelo seu navegador? Encontre a mensagem RED29004! Página de teste. Onde (em qual campo) encontra-se? Qual a diferença entre os endereços (IP) de origem e destino entre a mensagem GET e a de resposta do HTTP? PARTE 2 - Interação Básica GET/Resposta do HTTP usando TELNET e REQUISIÇÃO MANUAL Vamos repetir o acesso aos links acima, porém sem usar o navegador. A ideia é que nós façamos o papel de navegador. Isso deve ser feito com os seguintes passos: Coloque o Wireshark para capturar pacotes Abra um terminal de texto no Linux (menu Aplicativos->Acessórios->Terminal). Execute este comando: telnet tele.sj.ifsc.edu.br 80 Após aparecer esta linha: Trying 200.135.37.75... Connected to integrado.sj.ifsc.edu.br. Escape character is '^]'. digite o seguinte: GET /~odilson/RED29004//RED29004.html HTTP/1.0 e em seguida tecle ENTER duas vezes. Identifique a página html que foi enviada como resposta. Compare o resultado das execuções desses comandos com o que se viu no navegador. Qual a diferença em cada caso ? Identifique os componentes do sistema de comunicação de dados nesse acesso direto (quem é cliente, quem é servidor) Refaça um pedido em que o recurso é inexistente no servidor (ex: página html com nome inexistente). Observe a resposta. Refaça um pedido para o recurso default e veja o código de resposta: GET / HTTP/1.0 Refaça o pedido usando o HTTP/1.1 e tente inferir a diferença da versão 1;0. Note que o GET nesta versão deve ser realizado com o campo Host: GET /~odilson/RED29004//RED29004.html HTTP/1.1 Host: tele.sj.ifsc.edu.br No teste anterior deve ter observado que a conexão se manteve aberta. Experimente refazer o pedido para um outro recurso na mesma conexão: GET /~odilson/RED29004//RED29004_arq2.html HTTP/1.1 Host: tele.sj.ifsc.edu.br Esta característica é a "persistência" do http versão 1.1, que permite reutilizar a mesma conexão para adquirir múltiplos recursos.

Laboratório 4 - Desvendando o HTTP com Wireshark - AVANÇADO

Objetivos Explorar GET Condicional/Resposta no protocolo HTTP: Documentos HTML com Objetos Incluídos Segurança com HTTPS, PARTE 1 - A Interação HTTP GET Condicional/Resposta A maioria dos navegadores web tem um cache (seção 2.2.6 do livro) e, desta forma, realizam GET condicional quando baixam um objeto HTTP. Execute os seguintes passos: inicie o navegador web; limpe o cache do seu navegador(Ctrl + Shift + Del); inicie o Wireshark; digite o URL no navegador http://tele.sj.ifsc.edu.br/~odilson/RED29004//RED29004.html seu navegador deve exibir um arquivo em HTML muito simples com duas linhas; pressione o botão “refresh” (F5) no navegador (ou digite o URL novamente); pare a captura de pacotes, e digite “http” na caixa de texto de especificação de filtro, para que apenas as mensagens HTTP sejam apresentadas na janela de listagem de pacotes. Responda às seguintes questões: Inspecione o conteúdo da primeira mensagem HTTP GET do seu navegador para o servidor tele.sj.ifsc.edu.br. Você vê uma linha “If-Modified-Since”? Inspecione o conteúdo da resposta do servidor. O servidor retornou explicitamente o conteúdo do arquivo? Como você pode dizer isso? Agora inspecione o conteúdo da segunda mensagem HTTP GET do seu navegador para o servidor. Você vê uma linha “If-Modified-Since”? Caso a resposta seja afirmativa, qual informação segue o cabeçalho “If-Modified-Since”? Qual é o código de status e a frase retornada do servidor na resposta à segunda mensagem HTTP GET? É diferente do código de retorno da primeira mensagem? O servidor retornou explicitamente o conteúdo do arquivo? Explique. Qual o tamanho da primeira e segunda mensagem de retorno do servidor? PARTE 2 -Documentos HTML com Objetos Incluídos Agora que vimos como o Wireshark mostra o tráfego capturado para arquivos em HTML grandes, nós podemos observar o que acontece quando o seu browser baixa um arquivo com objetos incluídos, no nosso exemplo, imagens que estão armazenadas em outros servidores. Faça o seguinte: inicie o navegador web; limpe o cache do seu navegador; inicie o Wireshark; digite o URL no navegador http://tele.sj.ifsc.edu.br/~odilson/RED29004/RED29004_arq3.html seu navegador deve exibir um arquivo pequeno em HTML com duas imagens incluídas. Estas duas imagens estão referenciadas no arquivo em HTML. Isto é, as imagens não estão no arquivo em HTML, ao invés disso, há um URL para cada imagem no arquivo em HTML. Como discutido no livro, seu navegador terá que baixar estas imagens dos locais correspondentes. As imagens estão em docente.ifsc.edu.br; Verifique o código fonte da página, clicando com o botão direito sobre ela. Observe os links dentro do código html. digite o URL no navegador http://tele.sj.ifsc.edu.br/~odilson/RED29004/RED29004_arq4.html seu navegador deve exibir um arquivo pequeno em HTML com cinco imagens incluídas. Estas cinco imagens,diferentemente do caso anterior, estão depositadas no próprio sítio do professor; Verifique o código fonte da página, clicando com o botão direito sobre ela. Observe os links dentro do código html. pare a captura de pacotes, e digite “http” na caixa de texto de especificação de filtro, para que apenas as mensagens HTTP seja exibidas. Responda às seguintes questões: Quantas mensagens HTTP GET foram enviadas pelo seu navegador em cada acesso? Para quais endereços na Internet estas mensagens foram enviadas em cada acesso? Você consegue dizer se o seu navegador baixou imagens com ou sem paralelismo? Explique e diferencie o comportamento em cada um dos casos. PARTE 3 -Segurança com HTTPS Para finalizar, vamos capturar sequências de mensagens HTTPS, somente a título de comparação. Execute os seguintes procedimentos: inicie o navegador web; limpe o cache do seu navegador; inicie o Wireshark; digite o seguinte URL no navegador https://www.ssllabs.com/ssltest/; pare a captura de pacotes e digite "ssl" na caixa de texto de especificação de filtro, para que apenas as mensagens criptografadas sejam exibidas. Responda: Compare a sequência de troca de mensagens (GET e resposta) entre o HTTP (das seções anteriores) com o ssl, existe alguma similaridade? Que tipos de campos são mais presentes nesse tipo de mensagens? Você consegue identificar o conteúdo de alguma nas mensagens ssl, como no caso das mensagens http?

Laboratório 5 - Servidor Apache e Construção de Página HTML

Objetivos Introdução aos Protocolos de Aplicação Colocando o servidor Apache no AR no Netkit Implementando páginas HTML Máquinas Virtuais UML / Netkit2 Para esta aula de laboratório estaremos usando o netkit2 do Prof.Sobral, uma extensão do netkit da Universidade de Roma Tre. Trata-se de uma ferramenta que que permite criar máquinas virtuais leves sobre o linux. Estas máquinas podem ser ligadas em rede. Neste laboratório conectaremos uma máquina virtual na REDE do Laboratório através de uma bridge. O Servidor Apache Neste laboratório vamos criar uma página html e hospedá-la em um máquina virtual com o Web Server Apache. Para maiores informações consulte Visão Geral do Apache . Colocando o servidor Apache no AR no Netkit Inicialmente vamos colocar um Máquina Virtual (VM) Netkit conectada com uma bridge para que possamos acessá-la de qualquer lugar do laboratório. Utilize o editor de texto Gedit e salve as definições do laboratório abaixo em um arquivo lab.conf na pasta /home/aluno: pc1[type]=generic pc1[eth0]=uplink:bridge=eth0:ip=dhcp </syntaxhighlight> Rode o netKit em seu computador. Em um terminal digite: netkit2 & </syntaxhighlight> No menu File - Load and Run, procure o arquivo /home/aluno/lab.conf e clique em OK. Abrirá um terminal da máquina virtual (VM) que estará rodando servidor Apache que vamos utilizar, onde é possível fazer a configuração do mesmo. Ao clicar no menu File - Graph, pode-se ter uma visão da rede a ser simulada e conferir se é equivalente ao diagrama proposto. Identifique o IP da VM usando o comando ifconfig. Teste a conectividade entre a máquina virtual e a máquina hospedeira. Coloque o servidor apache em execução. Este servidor escutará na porta 80 por pedidos de páginas.Execute no terminal da VM: /etc/init.d/apache2 start </syntaxhighlight> Abra o Firefox na sua máquina (hospedeira) e coloque como endereço: http://endereco_IP </syntaxhighlight> Pronto. Você está acessando a página default do Apache da VM. Você pode verificar o arquivo de definição da página default com o comando: cat /var/www/index.html </syntaxhighlight> na máquina virtual. Com sua experiência com o Wireshark capture as mensagens trocadas entre o servidor da VM e seu navegador. Localize os comandos GET e a resposta do servidor. Observe quais são os IPs de destino e fonte da requisição e resposta. Observe as portas de destino e fonte da requisição e resposta. Qual versão do HTTP está sendo usada? Colocando no ar a sua página HTML Nesta parte do experimento vamos editar um código HTML e disponibilizá-la em um diretório de um usuário criado por você. Observe que vamos editar a página no hospedeiro e salvá-la em um diretório compartilhado entre a máquina hospedeira e a MV. Siga as instruções do professor e, usando o Gedit, salve o código html abaixo como um arquivo chamado index.html na pasta /home/aluno/lab/shared da sua máquina hospedeira. <!DOCTYPE html> <html> <body> Alo Mundo Estamos sendo visitados por extraterrestres... </body> </syntaxhighlight> Entre no terminal da VM e crie um usuário: adduser alien </syntaxhighlight> Ainda na VM vá até o diretório deste usuário: cd /home/alien </syntaxhighlight> Neste diretório, crie um subdiretório para conter a página html: mkdir public_html </syntaxhighlight> Entre no diretório e copie a página criada, com os comandos: cd public_html cp /hostlab/shared/index.html ./ </syntaxhighlight> Certifique-se que o arquivo foi copiado com o comando: ls </syntaxhighlight> o qual deverá retornar o nome do arquivo. Informe ao apache que os diretórios public_html dos usuários podem ser acessados: a2enmod userdir </syntaxhighlight> Reinicie o Apache /etc/init.d/apache2 restart </syntaxhighlight> Você deve ser capaz agora de acessar esta pagina através do seu navegador no hospedeiro usando o endereço: http://end_IP/~alien </syntaxhighlight> Se desejar, é possível personalizar a página acrescentando novas frases, para isso repita os passos: 1, 5 e 9.

Laboratório 6 - Serviço de Nomes (DNS)

Objetivos O Domain Name System (DNS) traduz nomes de hosts em endereços Internet Protocol (IP), preenchendo uma lacuna crítica na infraestrutura da Internet. Neste laboratório, observaremos mais de perto: o lado cliente do DNS, uma pequena análise do protocolo e consultas AAAA Lembre-se de que o papel do cliente no DNS é relativamente simples - um cliente envia uma consulta ao seu DNS, e obtém uma resposta. Muito pode acontecer “por baixo dos panos”, de forma invisível aos clientes DNS, enquanto os servidores DNS, organizados hierarquicamente, comunicam-se entre si para, ou recursivamente ou iterativamente, resolver uma consulta DNS de um cliente. Do ponto de vista do cliente DNS, contudo, o protocolo é bastante simples - uma consulta é feita ao seu servidor DNS e uma resposta é recebida deste servidor. Consultas DNS por meio de ferramentas especializadas Usando o programa host, Nslookup ou dig, que são executados no terminal, descubra e anote no relatório os endereços IP associados aos seguintes nomes de hosts (máquinas): mail.ifsc.edu.br www.google.com www.gmail.com Agora descubra e anote no relatório quem é o servidor DNS responsável por cada um dos domínios dos nomes acima. Para isso consulte o valor do registro NS associado a esses domínios. Por exemplo, com o programa host ou dig isso pode ser feito assim: host -t ns ifsc.edu.br dig -t ns ifsc.edu.br Descubra e anote no relatório: qual o servidor DNS usado pelo seu computador? Num terminal digite: cat /etc/resolv.conf caso a resposta seja "nameserver 127.0.1.1" (endereço de loopback), provavelmente o sistema gráfico está controlando sua interface, nesse caso execute: nm-tool | tail -n 8 O serviço DNS fornece outras informações além do endereço IP associado a cada nome de domínio e/ou máquina. Por exemplo, como ele pode-se descobrir que host recebe emails em um determinado domínio. Isso é utilizado pelos MTA (Mail Transfer Agent) mundo afora para entregarem emails para seus destinatários (lembre que isso se faz com o protocolo SMTP). Para descobrir essa informação, deve-se consultar o registro MX (Mail eXchange) de um domínio. Novamente as ferramentas a ser utilizada nesse caso podem ser host ou dig. Por exemplo: host -t mx ifsc.edu.br dig -t mx ifsc.edu.br Descubra e anote no relatório quem é o servidor de emails nos seguintes domínios: gmail.com hotmail.com ifsc.edu.br Outra informação útil guardada por servidores DNS é a tradução de endereço IP para nome de domínio. Isso é chamado de tradução reversa (ou DNS reverso). Usando os programas de diagnóstico já vistos, isso pode ser feito assim: dig -x 200.135.37.65 ... o dig tem um resultado um pouco mais carregado que os outros utilitários (host e nslookup), porém neste caso é mais prático. Veja o resultado da consulta logo após a linha ;; ANSWER SECTION:. Experimente fazer a resolução reversa para cada um dos IP obtidos nas consultas realizadas no primeiro exercício desta atividade. Pode-se também usar a variante do dig para respostas curtas: dig -x 200.135.37.65 +short </syntaxhighlight> Faça uma consulta recursiva com dig e responda: dig +trace mail.ru. Qual foi o RLD (Root Level Domain) consultado? Qual o TLD (Top Level Domain) consultado? Qual o SLD (Second Level Domain) consultado? Como você sabe que foram esses os LDs consultados? Como explicado durante a aula e visto no exercício anterior, DNS é um banco de dados distribuído. Isso quer dizer que suas informações estão espalhadas em milhares (ou milhões?) de servidores DNS mundo afora. Cada servidor DNS mantém os dados dos domínios por que é responsável. Será que é possível rastrear todos os servidores DNS que devem ser consultados até chegar ao servidor do domínio procurado? Posto de outro modo, vamos fazer todo o processo de requisição interativa, do exercício anterior, manualmente, ou seja, descobrir quem é o Root Level Domain, o Top Level Domain e o Second Level Domain. Anote no relatório. Descubra quem são os servidores raiz (topo de hierarquia DNS): host -t ns . dig -t ns . Escolha um dos servidores TLD listados, e use-o para fazer as consultas. Por exemplo: host -v -t a www.sj.ifsc.edu.br. j.root-servers.net. ... e observe a seção ;; AUTHORITY SECTION:. Ele contém a listagem de servidores DNS que podem atender sua consulta. Continue fazendo as consultas aos servidores DNS listados, até conseguir traduzir o nome requisitado. Por exemplo: host -v -t a www.sj.ifsc.edu.br. b.dns.br </syntaxhighlight> Quantos servidores DNS foram necessários consultar no total? Consultando um servidor explícito(@) dig @j.root-servers.net. +trace www.sj.ifsc.edu.br. Explique a diferença na consulta realizada por esse comando para o comando dig +trace www.sj.ifsc.edu.br. Em algum caso a consulta poderia ser exatamente a mesma? Qual? Algumas consultas AAAA Vamos expandir um pouco nossos horizontes e fazer algumas consultas envolvendo IPv6. No terminal de sua máquina faça uma consulta e responda: qual o endereço IPv6 dos hosts? Por exemplo: dig AAAA google.com host -t AAAA google.com </syntaxhighlight> webmail.ufsc.br www.sj.ifsc.edu.br www.nyt.com ipv6.br www.microsoft.com Agora vamos fazer a consulta reversa. Qual é o nome de host dos seguintes endereços? Por exemplo: dig -x 2001:12ff::10 dig -x 2001:12ff::10 +short host 2001:12ff::10 </syntaxhighlight> 2801:84:0:2::10 2001:12d0:0:126::183:244 2001:12ff::10 2804:1454:1004:100::2 Analisando o protocolo via Wireshark Agora que já está ficando claro como funcionam as consultas DNS, deve-se investigar como se dá a comunicação entre seu computador e seu servidor DNS. abra o navegador web e limpe o cache do mesmo; abra o Wireshark e escolha a interface e inicie a captura de pacotes; inicie a captura de pacotes no Wireshark; no terminal digite dig +trace canon.jp (isso vai provocar a consulta DNS); pare a captura de pacotes; No Wireshark digite “dns” no filtro (sem as aspas); Com base nisso identifique o seguinte: quantas mensagens são trocadas entre cliente e servidor DNS para cada consulta? que protocolo de transporte é usado? que portas de origem e destino são utilizadas? qual o formato das mensagens DNS? Elas são textuais como as mensagens HTTP? qual o tipo de registro DNS acessado em cada consulta? que informações estão contidas nas respostas DNS? Há algo além do que foi pedido? qual o tamanho das mensagens DNS? qual endereço IP a mensagem de consulta DNS é enviada? Foi o mesmo ip obtido na seção anterior: seu servidor DNS? examine a mensagem de consulta DNS. Qual o campo “type” desta mensagem? a mensagem de consulta contém algum campo “answer”? examine a mensagem de resposta DNS. Quantos campos com “answer” existem? quais são os benefícios de usar o UDP ao invés do TCP como protocolo de transporte para o DNS? Exemplos de arquivos de um Second Level Domain fictício Exemplo de arquivos de configuração de um servidor BIND /etc/bind/db.redes $TTL 86400 @ IN SOA ns.redes.edu.br. root ( 2016090900 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 86400 ) ; Negative Cache TTL @ IN NS ns.redes.edu.br. @ IN MX 10 mail.redes.edu.br. $ORIGIN redes.edu.br. ns A 192.168.1.101 www A 192.168.1.102 www A 192.168.1.103 www A 192.168.1.104 www A 192.168.1.105 www A 192.168.1.106 www A 192.168.1.107 ftp A 192.168.1.108 mail A 192.168.1.109 </syntaxhighlight> /etc/bind/db.2.168.192 (Zona reversa) $TTL 86400 @ IN SOA ns.redes.edu.br. root ( 2016090900 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 86400 ) ; Negative Cache TTL IN NS ns.redes.edu.br. 101 IN PTR ns.redes.edu.br. 102 IN PTR www.redes.edu.br. 108 IN PTR ftp.redes.edu.br. 109 IN PTR mail.redes.edu.br. </syntaxhighlight>

Laboratório 7 - Observando outros procolos de aplicação

Transparências utilizadas durante as aulas

Capítulo 1 - Introdução

Capítulo 2 - Camada de Aplicação