Projeto 1 Redes Akira

Prévia do material em texto

UNIVERSIDADE FEDERAL DE GOIÁS 
INSTITUTO DE INFORMÁTICA 
SISTEMAS DE INFORMAÇÃO 
REDES DE COMPUTADORES MARCELO AKIRA INUZUKA 
 
PARTICIPANTES: 
GABRIELA N. MANSUR 
MARCELLA SUEIZY M. DE TOLEDO 
 
 
 
 
PROJETO 1 – SEMESTRE 2/2015 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
GOIÂNIA 2015 
SEÇÃO 1 
1.1 Introdução 
O conteúdo deste projeto faz referência ao trabalho semestral da disciplina 
de Redes de Computadores do semestre 2/2015 e se baseia em capturas de 
telas e detalhamento gerais de comandos e descrições de termos e métodos 
de configuração de rede, focado na construção de uma rede interna. 
 
1.2 Objetivos 
O referido projeto tem como objetivo apresentar a parte prática da disciplina 
em questão, abrangendo todos os aspectos, referências, comandos e 
conhecimento agregado à disciplina. O objetivo específico deste será a 
configuração de uma rede local constituída de duas máquinas virtuais, sendo 
uma bridge e a outra rede interna, de modo a estabelecer tanto a 
conectividade entre máquinas quanto acesso à internet, além de acesso a 
outros serviços de aplicação como email, verificando e analisando todos os 
aspectos da rede, como roteamento, simulação de envio de pacotes e etc. 
 
1.3 Membros do Grupo 
Atualmente o grupo é formado por Gabriela N. Mansur e Marcella Sueizy M. 
de Toledo. 
 
1.4 Arquitetura da Rede 
A seguinte figura demonstra a arquitetura proposta: 
 
 
Figura 1 – Arquitetura de rede. 
 
1.5 Descrição de softwares 
utilizados: 
 
- Oracle MV VirtualBox 
- Servidor DNS Bind9 
- Servidor Web Apache 
- Servidor SMTP, POP3 e 
IMAP 
- Wireshark Network 
Analyser 
- Cliente de email Icedove 
SEÇÃO 2 – Configurações Básicas de Rede 
2.1 Interfaces de Rede da MV1 
2.1.1 - Configurações da MV1 para Bridge no Adaptador 1 e Rede 
Interna no Adaptador 2 na Virtual Box. 
 
 
 
 
 
 
 
2.1.2 Configurações atuais da MV1 com ifconfig. 
 
2.1.3 Pingando o site www.ufg.br na MV1 para teste de conectividade 
com roteador. 
 
 
2.1.4 Mudança de IP para o IP definido por grupo, no caso 10.7.0.1 para 
grupo 7 
 
 
 
 
 
 
 
 
 
 
 
 
2.2 Interfaces de Rede da MV2 
2.2.1 Configurações da MV2 para Rede Interna no Adaptador 1 na 
Virtual Box. 
 
2.2.2 Configuração atual na MV2 com ifconfig. 
 
 
 
 
 
2.2.3 Mudança de IP para o IP definido por grupo, no caso 10.7.0.2 para 
grupo 7 e participante do subgrupo de 10.7.0.1. 
 
 
2.3 Roteamento 
2.3.1 MV2 não pinga no site www.ufg.br, falta as configurações de 
roteamento para MV1 e configuração DNS. 
 
 
 
 
2.3.2 Configurações de route da MV2, sem rota default para MV1 
(10.7.0.1). 
 
2.3.3 Adicionando rota para MV1 pelo comando route add –net default 
gw. 
 
2.3.4 Habilitação de roteamento na MV1 acessando 
/proc/sys/net/ipv4/ip_forward, ajustando o seu valor para “1” para rotear. 
 
2.3.5 Teste ping da MV2 na MV1. 
 
 
 
2.3.6 Traceroute de MV2 para MV1. 
 
2.4 Cliente DNS 
2.4.1. Verificando DNS da MV2 acessando /etc/resolv.conf. 
 
2.4.2. Ajustando DNS na MV2 adicionando o valor “nameserver 8.8.8.8” 
(DNS Google) ao arquivo de configuração de nomes (resolv.conf). 
 
2.4.3. Teste de Resolução de nomes 
 
 
 
2.5 Network Address Translation 
2.5.1. Adicionado regras de conectividade (já estava configurado, mas 
refiz o procedimento duplicando a regra) por acesso a iptables. 
 
2.5.2. Com as configurações feitas, fiz o teste por ping acessando um 
endereço em MV2 para www.ufg.br. 
 
2.5.3. Tornando as configurações de Interface e IPTables persistentes na 
MV1, e verificando após reinicio. 
2.5.3.1. Acesso a interfaces por nano /etc/network/interfaces: 
 
2.5.3.2. Acesso ás configurações de roteamento por nano 
/etc/sysctl.conf, descomentando a linha referente ao packet forwarding para salvar a 
configuração de MV1 servir de roteadora de MV2: 
 
2.5.3.3. Salvando as configurações de regras de roteamento por 
iptables-save > /etc/iptables.conf e verificando a data de save: 
 
 
 
 
 
 
 
 
 
 
2.5.3.4. Configuração adicional, restaurando ao estado que salvamos 
o iptables logo quando é feito up na eth0 : 
 
2.5.3.5. Verificação, após reinicio da máquina, da persistência das 
configurações em MV1: 
2.5.3.5.1. Interfaces: 
 
 
2.5.3.5.2. Roteamento: 
 
2.5.4. Tornando a configuração de Interface persistente na MV2, e 
verificando após reinicio: 
2.5.4.1. Acesso a interfaces por nano /etc/network/interfaces e 
gravando as configurações de roteamento e ip fixo: 
 
 
2.5.4.2. Verificação, após reinicio da máquina, da persistência 
das configurações em MV2: 
2.5.4.2.1. Interfaces: 
 
 
 
 
2.5.4.2.2. Roteamento: 
 
2.6 Teste Tcpdump 
 2.6.1. Primeiramente tive que executar o comando apt-get install 
tcdump em ambas as Maquinas Virtuais de modo a reconhecerem o comando 
tcpdump (apesar de que fizemos o tcpdump apenas de MV1 para MV2). 
Posteriormente, na MV1 dei o comando tcpdump –v icmp, e na MV2 ping 
www.google.com, resultando no tráfego demonstrado: 
2.6.2. – tcpdump em MV1 
 
2.6.3. ping em MV2 
 
SEÇÃO 3 – Configuração DNS 
3.1 Descrição do protocolo 
O DNS (Domain Name Service) é um serviço da rede modelo TCP/IP da camada 
de Aplicação que tem como finalidade converter nomes em endereços IP e vice versa. O 
DNS funciona de duas maneiras, uma através da tabela de hosts e a outra através da 
consulta por um servidor DNS. A tabela de hosts funciona como uma listagem, de modo 
hierárquico, de todos os endereços de internet disponíveis, acessado através do arquivo 
named no pacote BIND (Berkeley Internet Name Domain). A consulta por servidor DNS 
acontece ao buscarmos num servidor de nomes o respectivo endereço que procuramos, 
sendo este servidor salvo no arquivo resolv.conf através da nomenclatura 
“nameserver”. Citado anteriormente, a tabela de host que está contida no pacote BIND 
é um dos componentes do DNS, sendo nomeado como Espaço de Nomes e Registro de 
Recursos, sendo ele a base e as ramificações dos serviços de busca dos endereços. Outra 
propriedade do DNS são os Servidores de Nomes, local onde é armazenado a estrutura 
dos nomes e domínios. Em terceiro fica o Resolvedor, o qual faz papel de identificar o 
tipo de requisição de uma aplicação por serviço DNS e a encaminha para um servidor 
DNS. Por padrão, o DNS utiliza o protocolo de transporte UDP na porta 53, por ter um 
maior desempenho e rapidez, já que UDP não é orientado a conexão, não sendo 
necessário controle de fluxos e garantias de entrega. 
O RFC’s (Request For Comments) são documentos técnicos que descrevem os 
aspectos e o funcionamento do protocolo que ele cita. Tais documentos são mantidos 
pelo IETF (Internet Enginnering Task Force). Esses documentos possuem acesso público 
e podem ser modificados conforme a evolução de algum protocolo e podem ficar 
obsoletos conforme novos protocolos são criados. Em reação ao DNS, o RFC que o 
formaliza é o 1034 e o 1035. 
3.2 BIND 
3.2.1 – Instalando Bind, o servidor de nomes escolhido, na MV2: 
 
 
 
 
 
3.2.2 – Verificando o conteúdo do diretório Bind: 
 
 3.2.3 – Instalando Dnsutils para utilizar a ferramenta host e dig: 
 
 3.2.4 – Verificando o servidor que responde pelo endereço 
www.inf.ufg.br, através do comando dig, um modelo detalhado da resolução de 
nomes: 
 
 
 
 
 
 
 
 3.2.5 – Utilizando o comando host, simplificaçãodo comando dig, 
devolvendo o nome da máquina: 
 
 3.2.6 – Adicionando no arquivo de configuração de resolução de nomes 
(resolv.conf) o nameserver local, 127.0.0.1, para que seja resolvida na própria máquina 
os nomes dos endereços: 
 
 3.2.7 – Entrando e editando o arquivo Bind referente ao cadastro das 
zonas, determinando a zona correspondente ao grupo7.inf.ufg.br como o master. O 
acesso é ao arquivo named.conf.local:
 
 3.2.7 – Editando o arquivo que contém os hospedeiros e seus nomes 
resolvidos referentes a zona do grupo 7. Essa configuração está no diretório do Bind 
em db.grupo7.inf.ufg.br: 
 
 
 
 3.2.8 – Reiniciando o Bind para que as opções sejam efetivadas:
 
 
 
 
 
 
 
 
 
 
 
 
 3.3 - Configurando o Mail Excharger (MX) definindo grupo7.inf.ufg.br sera o 
hospedeiro de mail. 
 
 3.4 – Testando o sucesso das configurações realizadas pelo comando host. 
 
 
 
 
3.4.1 Mudança na MV1, alterando o nameserver para o ip da MV2 para 
que reconheça os hosts configurados em db.grupo7.inf.ufg.br. 
 
 
 
 
 
SEÇÃO 4 – Configuração HTTP 
4.1 - Descrição do protocolo 
HTTP é a sigla para HyperText Transfer Protocol, protocolo da camada de aplicação e 
normalmente utiliza a porta 80 conectar á internet. Este protocolo não funciona por si 
só, necessitando fazer requisições de conteúdo á rede, na espera de devolver as 
informações requisitadas. Essa transferência é feita por links, os quais direcionam a um 
lugar (página de internet) que contém os dados solicitados, ou seja, o sistema funciona 
baseado em requisições e reposta entre cliente e servidor. Este é definido pela RFC 2616 
 Para que o protocolo HTTP funcione corretamente, os protocolos TCP e IP devem 
estar bem configurados, assim como DNS. 
 A conexão funciona da seguinte forma: tudo é feito por mensagens. O protocolo 
HTTP conecta-se por sua porta e pede uma conexão, assim ele recebe um “ok” e está 
apto a fazer um “get” das informações em um endereço especifico. Essa mensagem é 
composta de linha inicial, cabeçalho, linha espaço e o corpo da mensagem. Esta primeira 
linha define qual a requisição, onde ela está, e qual versão do protocolo HTTP ela vai 
usar. A cada requisição feita, ao fim do pedido ou no recebimento do mesmo, a conexão 
é fechada na versão 1.0, e na 1.1 existe um timeout que determina o fim da conexão. 
 Os principais métodos utilizados são GET, para solicitar recursos, HEAD, que 
assemelha-se ao get mas não devolve conteúdo, o POST, que envia dados a serem 
processados, PUT, que envia certo recurso, DELETE, auto explicativo, TRACE ecoa o 
pedido, demonstrando os servidores intermediários, OPTIONS, verifica esses métodos 
aceitos pelo HTTP e CONECT, usado para conexão segura. 
 Existem vários status que uma requisição pode obter, entre eles 200 (OK), 301 
(Moved Permanently – recurso removido permanente), 302 (Found – recurso removido 
temporariamente), 304 (Not Modified – conteúdo não modificado), 401 (Unauthorized 
– para conexão exige-se autenticação), 403 (Forbidden – o servidor recusa a requisição), 
404 (Not Found – não encontrado), entre outros. 
 
4.2 – Web Apache, instalando e verificando o status dos serviços alterando 
apache/init.d, em MV1 e em MV2. 
 4.2.1 – MV1: 
 
 4.2.2 – MV2: 
 
 
 4.3 Visualizando o conteúdo de /var/www/index.html na MV1 e acessando pelo 
telnet e comando GET do protocolo HTTP o conteúdo do arquivo e pelo navegador: 
 
 
 
4.4 – Na MV2, criar um arquivo de nome teste.txt e fazer os mesmos testes 
anteriores: 
 4.4.1 – Alterando a permissão em /var/www para criação de arquivos na 
pasta: 
 
 4.4.2 – Criando arquivo teste.txt e verificando seu conteúdo:
 
 4.4.3 – Fazendo os testes por telnet e no navegador:
 
 4.5 – Baixar a imagem disponível em 
http://www.inf.ufg.br/sites/default/files/marca-ufg.png e refazer os testes do item 
4.3. 
4.5.1 - Baixando a imagem marca-ufg.png pelo comando wget e 
salvando na pasta /var/www: 
 
 4.5.2 – Pegando o conteúdo fornecido pela imagem com get: 
 
 4.5.3 – Visualizando da mesma forma no navegador: 
 
 4.6 – Criar os domínios virtuais de ww1 e ww2 e testar a requisição de um 
arquivo teste.html de conteúdos diferentes em MV1 e MV2. 
 4.6.1 – Criando teste.html em MV1 e em MV2 respectivamente: 
 
 
 
 4.6.2 – Fazendo o teste de requisição do arquivo pela MV2 para MV1 
por telnet e navegador: 
 
 
4.6.3 – Fazendo o teste de requisição do arquivo pela MV1 para MV2 
por telnet e navegador: 
 
 
 
 
4.7 – Criar e armazenar uma pagina html simples que contenha a marca-
ufg.png como conteúdo e fazer análise de tráfego com Wireshark, usando o domínio 
virtual de www1. 
 4.7.1 – Criar o html teste.html contendo a imagem marca-ufg.png na 
MV1: 
 
 4.7.2 – Instalando o Wireshark para análise de tráfego: 
 
 4.7.3 – Fazendo o teste com o Wireshark da requisição do conteúdo de 
MV1 para MV2: 
 
a) A comunicação é feita da seguinte forma: é feita uma requisição 
de conexão entre a mv2 (10.7.0.2) e a mv1 (10.7.0.1) por sincronia, por TCP. 
A mv2 manda um SYN para ativação da conexão, em resposta a mv1 
responde que recebeu a requisição com SYN-ACK, e manda a resposta de 
conexão com o servidor por ACK. Esse é o método hand-shaking de 
confirmação de conexão. Em seguida a mv2 solicita o conteúdo em mv1 da 
página requisitada, mv1 manda um ACK de recebimento do pedido e devolve 
o conteúdo. A mv2 manda um ACK de recebimento. Depois a mv2 solicita a 
imagem a mv1, ela recebe a solicitação enviando um ACK, devolve o 
conteúdo e a mv2 manda ACK de confirmação. 
 
b) Foram dados 2 GETS. 
c) Foram 13 quadros Ethernet. 
08:00:27:c9:be:b5 == MV2 == 10.7.0.2 
08:00:27:53:34:13 == MV1 == 10.7.0.1 
QUADRO 1 74 bytes 
 Origem: 08:00:27:c9:be: b5 Destino: 08:00:27:53:34:13 
QUADRO 2 74 bytes 
 Origem: 08:00:27:53:34:13 Destino: 08:00:27:c9:be: b5 
QUADRO 3 66 bytes 
 Origem: 08:00:27:c9:be: b5 Destino: 08:00:27:53:34:13 
QUADRO 4 383 bytes 
 Origem: 08:00:27:c9:be: b5 Destino: 08:00:27:53:34:13 
QUADRO 5 66 bytes 
 Origem: 08:00:27:53:34:13 Destino: 08:00:27:c9:be: b5 
QUADRO 6 547 bytes 
 Origem: 08:00:27:53:34:13 Destino: 08:00:27:c9:be: b5 
QUADRO 7 66 bytes 
Origem: 08:00:27:c9:be: b5 Destino: 08:00:27:53:34:13 
QUADRO 8 407 bytes 
Origem: 08:00:27:c9:be: b5 Destino: 08:00:27:53:34:13 
QUADRO 9 66 bytes 
 Origem: 08:00:27:53:34:13 Destino: 08:00:27:c9:be: b5 
QUADRO 10 1514 bytes 
 Origem: 08:00:27:53:34:13 Destino: 08:00:27:c9:be: b5 
QUADRO 11 66 bytes 
Origem: 08:00:27:c9:be: b5 Destino: 08:00:27:53:34:13 
QUADRO 12 1432 bytes 
 Origem: 08:00:27:53:34:13 Destino: 08:00:27:c9:be: b5 
QUADRO 13 66 bytes 
Origem: 08:00:27:c9:be: b5 Destino: 08:00:27:53:34:13 
d) Foram 13 quadros e todos tinham um IP encapsulado. 
 
QUADRO 1: 
Origem: 10.7.0.2 Destino: 10.7.0.1 
QUADRO 2: 
Origem: 10.7.0.1 Destino: 10.7.0.2 
QUADRO 3: 
Origem: 10.7.0.2 Destino: 10.7.0.1 
QUADRO 4: 
Origem: 10.7.0.2 Destino: 10.7.0.1 
QUADRO 5: 
Origem: 10.7.0.1 Destino: 10.7.0.2 
QUADRO 6: 
Origem: 10.7.0.1 Destino: 10.7.0.2 
QUADRO 7: 
Origem: 10.7.0.2 Destino: 10.7.0.1 
QUADRO 8: 
Origem: 10.7.0.2 Destino: 10.7.0.1 
QUADRO 9: 
 Origem: 10.7.0.1 Destino: 10.7.0.2 
QUADRO 10: 
 Origem: 10.7.0.1 Destino: 10.7.0.2 
QUADRO 11: 
Origem: 10.7.0.2 Destino: 10.7.0.1 
QUADRO 12: 
 Origem: 10.7.0.1 Destino: 10.7.0.2 
QUADRO 13: 
Origem: 10.7.0.2 Destino: 10.7.0.1 
e) Foram 13 quadros e todos tinham um TCP encapsulado. 
 
QUADRO 1: 
Origem:51434 Destino: 80 
QUADRO 2: 
Origem: 80 Destino: 51434 
QUADRO 3: 
Origem: 51434 Destino: 80 
QUADRO 4: 
Origem: 51434 Destino: 80 
QUADRO 5: 
Origem: 80 Destino: 51434 
QUADRO 6: 
Origem: 80 Destino: 51434 
QUADRO 7: 
Origem: 51434 Destino: 80 
QUADRO 8: 
Origem: 51434 Destino: 80 
QUADRO 9: 
Origem: 80 Destino: 51434 
QUADRO 10: 
Origem: 80 Destino: 51434 
QUADRO 11: 
Origem: 51434 Destino: 80 
QUADRO 12: 
Origem: 80 Destino: 51434 
QUADRO 13: 
Origem: 51434 Destino: 80 
 
 
f) Não foi encontrado nenhum pacote com UDP. 
g) Foram encontrados 4 pacotes com conteúdo HTTP, os pacotes 4, 6, 8 e 12. 
Os pacotes com protocolo TCP são todos, mas os que são em essência TCP 
são: 
QUADRO 1: 
Origem: 51434 Destino: 80 
QUADRO 2: 
Origem: 80 Destino: 51434 
QUADRO 3: 
Origem: 51434 Destino: 80 
QUADRO 5: 
Origem: 80 Destino: 51434 
QUADRO 7: 
Origem: 51434 Destino: 80 
QUADRO 9: 
Origem: 80 Destino: 51434 
QUADRO 10: 
Origem: 80 Destino: 51434 
QUADRO 11: 
Origem: 51434 Destino: 80 
QUADRO 13: 
Origem: 51434 Destino: 80 
 
h) No pacote 8 a MV2 faz um GET para o .png solicitando-o á MV1. A MV1 no 
pacote 9 manda um ACK de confirmação de pedido. No pacote 10 a MV1 
transfere um fragmento da imagem, no 11, MV2 confirma o recebimento da 
imagem e no 12 a imagem é totalmente transferida e no 13 é feito um ACK 
de confirmação de MV2 para MV1. 
 
 
 
 
SEÇÃO 5 – Configuração SMTP 
 5.1 – Descrição do protocolo 
O protocolo SMTP (Simple Mail Tranfer Protocol) é o protocolo padrão para o envio de 
e-mails via internet. Seu principal objetivo é transmitir mensagens de e-mail entre dois 
computadores, que podem ser ambos servidores, ou um deles pode ser uma máquina 
cliente em que se utiliza aplicativos de email como o Outlook. 
O Protocolo SMTP é baseado em comandos (cliente) e respostas (servidor). Todos os 
comandos SMTP geram uma resposta, e é considerada uma violação do protocolo SMTP 
o envio de um comando antes que o servidor dê a resposta do comando anterior. 
O SMTP é um protocolo de envio apenas, ou seja, não permite que um usuário 
descarregue as mensagens de um servidor. Para que isso seja possível, é necessário um 
cliente de e-mail que dê suporte ao POP ou IMAP. 
A transferência de mensagens envolve dois manipuladores de e-mails. O agente de 
usuário (MUA – Mail User Agent) e o agente de transferência (MTA – Mail Transport 
Agent). O primeiro permite que o usuário escreva a mensagem e a envie, enquanto o 
segundo é o responsável por enviar essa mensagem ao host de destino. 
O emissor SMTP coleta as mensagens que estão esperando na fila e as envia ao host de 
destino, onde existe um receptor SMTP. Este processo ocorre através de uma ou várias 
conexões TCP. Então, o receptor SMTP verifica o cabeçalho de cada mensagem e faz a 
entrega ao seu ou aos seus respectivos hosts de destino. 
Esse protocolo usa por padrão a porta 25 numa rede Transmission Control Protocol (ou 
465 para conexão criptografada via SSL). 
RFC’s relacionados ao portocolo SMTP: 
 
 
 
5.2 – Instalação do servidor SMTP Postfix e testes 
 5.2.1 – Instalação na MV1 e MV2: 
 
 
 
 
 
 
 
 
 
 
 
 5.2.2 – Configuração em ambas MV’s para o domínio padrão 
grupo7.inf.ufg.br. 
 
 5.2.3 – Testes de status em ambas MV’s do Postfix: 
 
 
 5.3 – Teste local de envio de mensagens: 
 5.3.1 – Teste em MV1: 
 
 
 5.3.1 – Teste em MV2: 
 
 
 
 
 
 
 
 
 
 
 
5.4 – Teste de envio para teste@grupo7.inf.ufg.br. 
 5.4.1 – Envio de email por telnet na porta 25 (SMTP) partindo de MV1 e 
recebendo em MV2, fazendo a leitura com mail (sem usuário root): 
 
5.4.2 – Envio de email por telnet na porta 25 (SMTP) partindo de MV2 e 
recebendo em MV1, fazendo a leitura com mail (sem usuário roo
 
 
a) Em ambos os casos, quando enviado para teste@grupo7.inf.ufg.br, a 
mensagem é recebida na MV oposta, ou seja, quando enviada por MV1, 
recebe-se na MV2 e vice versa. 
b) Não há direcionamento. 
 
SEÇÃO 6 – Configuração POP3 E IMAP 
 6.1 – Descrição do protocolo 
O protocolo POP - Post Office Protocol permite recuperar o seu correio num servidor 
distante (o servidor POP). Utilizado para consultar e-mails de maneira off-line. 
Uma das principais versões é POP3, a qual é atribuída a porta 110. O protocolo de 
transporte utilizado é o TCP. 
Tal como no caso do protocolo SMTP, o protocolo POP funciona graças a comandos 
textuais enviados ao servidor POP. Cada um dos comandos enviados pelo cliente 
(validado pela sequência CR/LF) é composto por uma palavra-chave, eventualmente 
acompanhada de um ou vários argumentos, e seguida de uma resposta do servidor POP, 
composta por um número e por uma mensagem descritiva. 
O protocolo POP3 gera a autenticação com a ajuda de um nome de utilizador e de uma 
palavra-passe, em contrapartida não é seguro porque as senha, assim como os e-mails, 
circulam de maneira não-criptografada na rede. 
Por outro lado, o protocolo POP3 bloqueia a caixa de correio durante a consulta, o que 
significa que uma consulta simultânea por dois utilizadores de uma mesma caixa de 
correio é impossível. 
RFC’s relacionados ao POP3: 
 
O protocolo IMAP é uma alternativa ao protocolo POP3 com mais recursos. Mas com 
esse protocolo é possível conexões simultâneas a mesmo conta configurada. Neste 
protocolo, também é mantido o mesmo status de mensagem no software de acesso ao 
e-mail como no servidor. 
Esse protocolo é ideal para a necessidade de se acessar a mesma conta de diversos 
lugares ao mesmo tempo. 
O protocolo IMAP utiliza a porta 143 e também utiliza como protocolo de transporte o 
TCP. 
RFC’s relacionados ao protocolo IMAP: 
 
 6.2 – Instalação do POP3 e IMAP pelo auxiliar courier, no caso apenas na MV2, 
alteração do servidor Postfix para salvar as novas mensagens em Maildir ao invés de um 
diretório para cada usuário. Fazer teste de envio de email local. 
 6.2.1 – Instalação na MV2 do POP3 por courier-pop: 
 
 
 
 
 
6.2.2 – Instalação na MV2 do IMAP por courier-imap: 
 
6.2.3 – Redirecionamento dos email para Maildir nas configurações do Postfix, 
reiniciando o servidor SMTP e verificando se ocorreu a mudança: 
 
 
 
 
 
 
 
 
 
 
 
 
6.2.4 – Fazendo teste de envio de email – verifique que na penúltima linha da 
imagem já pode-se observar a funcionalidade do POP3 na notificação de novo email na caixa 
de Maildir: 
 
6.3 – Verificando pela porta do POP3, 110, a recuperação do email enviado no passo 
anterior: 
 
 
 
6.4 – Verificando pela porta do IMAP, 143, a recuperação do email enviado no passo 
6.2: 
 
 6.5 – Instalação do cliente de email Icedove na MV2, configuração do mesmo e teste 
de envio e recebimento de email. 
 
 
 
 
 6.5.1 – Instalação do cliente de e-mails Icedove: 
 
 6.5.2 – Configurações iniciais do cliente (senha: 123456): 
 
 
 
 
 6.5.3 – Envio de email pelo telnet e verificando a chegada no Inbox do Icedove, 
verificando o conteúdo da mensagem: 
 
 
 
SEÇÃO 7 – Considerações finais, referências e bibliografia 
 7.1 – Considerações finais 
O presente trabalho possibilitou o aprofundamento dos termos e teoria explicadas em 
sala de aula, além de oferecer um método de visualização da abstração que são os 
protocolos de rede e a forma como eles interagem, possibilitando boa comunicação, 
fluidez e capacidade de uma rede em funcionar bem. 
Também como atributo do trabalho, este nos possibilitou conhecer referencias debusca, tutoriais e aumentou nossa bagagem prática. Verificamos que podemos tratar a 
configuração de rede muito bem esmiuçada e singular, de forma a caracteriza-la de 
acordo com as necessidades. Acreditamos que isso é um grande diferencial, tendo em 
vista a otimização das redes que futuramente utilizaremos em aplicações e nas 
corporações que trabalharemos. 
 7.2 – Referências bibliográficas 
DNS 
http://social.technet.microsoft.com/wiki/contents/articles/12550.entendendo-o-
servico-dns-pt-br.aspx 
http://www.kloth.net/services/nslookup-pt.php 
http://www.vivaolinux.com.br/artigo/Servidor-DNS-(bind9)-em-Debian-
Linux?pagina=5 
ICMP 
https://pt.wikipedia.org/wiki/Internet_Control_Message_Protocol 
TCDump 
http://www.rationallyparanoid.com/articles/tcpdump.html 
http://www.vivaolinux.com.br/dica/tcpdump-Monitorando-conexoes 
http://www.vivaolinux.com.br/dica/Comando-tcpdump-exemplos-de-uso 
Apache 
http://www.vivaolinux.com.br/artigo/Basico-do-Apache-no-Debian?pagina=3 
HTML 
http://www.htmlprogressivo.net/2013/10/IMG-tag-Como-colocar-uma-imagem-em-
um-site-O-atributos-ALT.html 
https://www.oficinadanet.com.br/artigo/459/o_protocolo_http 
https://nandovieira.com.br/entendendo-um-pouco-mais-sobre-o-protocolo-http 
 
SMTP, POP3 e IMAP 
www.hardware.com.br/tutoriais/servidor-email/instalando-postfix.html 
http://br.ccm.net/contents/282-os-protocolos-de-servico-de-mensagens-smtp-pop3-
e-imap4 
https://www.ietf.org/rfc.html