Relatório Projeto Final Gerência de Redes

Arthur Almeida Martins Filho#1,

#
Departamento de Engenharia Elétrica, Universidade de Brasília
Campus Universitário Darcy Ribeiro, Brasília-DF,Brasil
190084537@aluno.unb.br

Felipe Breno Melo de Azevedo#2,

#
Departamento de Engenharia Elétrica, Universidade de Brasília
Campus Universitário Darcy Ribeiro, Brasília-DF,Brasil
190106263@aluno.unb.br

Resumo — Documento relativo ao projeto final dos alunos Arthur
Almeida e Felipe Breno da disciplina Gerência de Redes,
ministrada pelo professor Georges Daniel.
Palavras chave — GNS3, VyOS, OSPF, DMZ, ZABBIX, Data
Center, EXOS, pfSense, Infraestrutura de Rede, Gerência, Core,
Distribuição, Acesso, Firewall.
I. Introdução
Esse documento em questão, tem como objetivo
mostrar detalhadamente os procedimentos, metodologias,
desenvolvimentos e configurações aplicadas de um
Network Security Center (NSOC) de pequeno porte no
contexto de um campus de uma instituição de ensino no
software GNS3.
Para a parte do campus decidimos utilizar uma topologia
que é muito utilizada em muitas empresas atualmente,
que é a topologia 3-tier, atendendo assim os requisitos do
projeto, pois essa topologia ficou dividida em 3 camadas
(Core, Distribuição e Acesso), é possível ver um exemplo
disso na Figura 2 e ver como realmente ficou na Figura 3.
O backbone composto por 4 roteadores VyOS para que
haja redundância e várias rotas para conectividade dos
dispositivos. Já o data center e a DMZ estão conectados
ao firewall, que faz a ligação com todas as áreas (DMZ,
camada Core, data Center e ao backbone), o firewall ficou
na parte central pois ele que faz o controle e segurança da
rede.

II. Materiais e Equipamento Utilizados

O software utilizado par a executar o

experimento foi o GNS3 na versão 2.2.38, emulador para
a configuração de topologias de redes de computadores.
A appliance usada para os roteadores foi o VyOS versão
1.29, já a utilizada para os switches EXOS foi a versão
32.1.1.6. As ferramentas usadas para o projeto foram o
Zabbix (utilizada para o monitoramento da rede), o sniffer
Wireshark (para analisar o tráfego dos pacotes) e o
pfSense (utilizado como firewall da rede).

III. Procedimentos e análises experimentais

Atividade nº1: Figura 1 - Informações referentes aos dispositivos da Infraestrutura

de Redes.
Esse projeto foi realizado com base nas
As imagens a seguir mostram um exemplo da
topologias dos projetos que foram feitos em sala de aula.
Decidimos montar uma topologia que segue uma topologia 3-tier que foi utilizada para atender todos os
topologia hierárquica, pois dessa forma conseguimos requisitos que foram pedidos, mostra também como ficou
seguir a tabela da Figura 1, onde a infraestrutura possui a topologia final na Figura 3.
dois campus (campus A e campus B, cada um com sua
vlan), um data center, uma DMZ, um backbone e ainda
utilizamos 2 ISP (NAT 1 e NAT 2) para acesso à extranet.
 Dispositivo Interface Endereço IP Endereço subrede Subrede Área OSPF
eth0 dhcp 192.168.200.0/24 0
eth1 dhcp 192.168.122.0/24 0
R1
eth2 192.168.15.1/30 192.168.15.0/30 #0 0
eth3 192.168.15.5/30 192.168.15.4/30 #1 0
eth0 192.168.15.9/30 192.168.15.8/30 #2 0
eth1 192.168.15.14/30 192.168.15.12/30 #3 0
R2
eth2 192.168.15.2/30 192.168.15.0/30 #0 0
eth3 0
eth0
eth1 192.168.15.13/30 192.168.15.12/30 #3 0
R3
eth2
eth3 192.168.15.6/30 192.168.15.4/30 #1 0
eth0 192.168.15.10/30 192.168.15.8/30 #2 0
eth1 172.24.15.1/24
ROT-UNB
eth2 192.168.15.18/30 192.168.15.16/30 #4 0
eth3 0

Figura 5 - Endereçamento IP de cada interface dos roteadores

A configuração de acesso a NAT foi feita

Figura 2 - Distribuição de SW (Core, Distribuição, Acesso)
Figura 3 -Distribuição de SW (Core, Distribuição, Acesso)
dividida em duas regras semelhantes para cada NAT. Na
rule 100 foi definida a interface eth0 como outbound, o
endereço da rede do backbone e a comunicação traduzida
como masquerade. Já na rule 200 foi definida a interface
eth1 como outbound, o endereço da rede do backbone e a
comunicação traduzida como masquerade. A NAT 1
consiste no link com a rede externa a partir da máquina
local, já a NAT 2 faz essa ponte com a rede externa a
partir do GNS3 VM. Dessa forma é garantida a
redundância de link com a rede externa.

- Divisão das áreas:
1- Backbone: O backbone tem como função
conectar diferentes redes de distribuição, essa
topologia deve ser confiável. A topologia do
projeto consiste em 4 roteadores conectados entre
si e com duas interfaces do roteador R1
conectadas à NAT, para que possa existir uma
redundância caso algum link de internet caia. As
tabelas a seguir mostram como ficou dividida a
faixa de endereçamento IP e o endereçamento IP
de cada interface de acordo com cada rede.
2- Data Center: O data center é um local físico que
reúne as operações da área de tecnologia da
informação e comunicação de uma organização,
para o processamento, armazenamento,
provisionamento de dados, serviços e aplicações.
Mas por se tratar de um local de estra importância
e com muitos dados sigilosos, deve haver
algumas restrições, seja ela física ou virtual.
Nesse projeto temos um Ubuntu Server
localizado no data center que está instalado via
Docker um servidor Zabbix que serve de
monitoramento e gerenciamento da rede.

A configuração do Backbone foi feita
conforme especificação nas tabelas abaixo:
Figura 4 - Intervalos de endereçamento IP
3- DMZ: Uma DMZ ou zona desmilitarizada é uma
sub-rede isolada da rede interna por um firewall
que protege e adiciona uma camada extra de
segurança à rede local interna de uma
organização contra tráfego não confiável advinda
da intranet e da extranet. O benefício de usar uma
DMZ é que ela promove uma maior segurança
para essa área “restrita”. No caso do projeto o
servidor FTP está localizado na DMZ. Essa
transferência de arquivos está ocorrendo na porta
 20 para dados e na porta 21 para controle, e essas
portas devem ser acessados por qualquer estação,
seja ela da intranet (LAN) ou da extranet, porém
somente esses protocolos pode gerar
transferência da intranet para a DMZ, nenhum
outro pode, e nem o seu servidor da DMZ pode
requisitar algum tipo de serviço para a intranet.
4- Core: Essa etapa da topologia só seria realmente
necessária caso a rede já esteja grande, porém por
fins acadêmicos, foi requisitado que essa parte da
topologia fosse inserida, mesmo que
desnecessário. O Core é o ponto onde acontece
todo o tráfego da rede, em alguns casos sendo até
necessário utilizar um EtherChannel, que tem
como objetivo agrupar vários ethernet links em
somente um link lógico, tendo como
consequência fornecer tolerâncias a falhas,
compartilhamento de carga, maior largura de
banda e redundância entre switches nesse caso.
A seguir estão as configurações dos
switches Core da nossa topologia:
Figura 6 - Configuração do CoreA
Figura 7 - Configuração do CoreB
5- Distribuição: Quando se fala de swicth de
distribuição já se lembra da topologia 3-tier, pois
nessa topologia a camada de distribuição é
responsável por fazer uma ponte entre a camada
de acesso e a camada core, ou seja, é a fronteira
entra a camada 2 e a camada 3. Para a nossa
topologia, estamos usando os switches de
distribuição como gateways para os hosts nos
campos, para que isso ocorra, os switches estão
operando com o protocolo VRRP (Virtual Router
Redundancy Protocol) para que tenha uma saída
com redundância para a intranet.
A seguir estão as configurações dos
switches de Distribuição da nossa topologia:
Figura 8 - Configuração do switch de DistribuiçãoA
Figura 9 - Configuração do switch de DistribuiçãoB
6- Acesso: O principal objetivo da camada de
acesso é interligar todos os dispositivos finais.
Como foi falado anteriormente, essa camada
opera puramente na camada 2 (camada de
enlace), e por isso, alguns protocolos estão
operando, como o STP (Spannig Tree Protocol)
que tem o objetivo de eliminar os links que estão
gerando loops na camada 2. Também nessa
camada, é realizado a divisão entre vlans.

A seguir estão as configurações dos

switches de Acesso da nossa topologia:

Figura 12 - Configuração do switch de Acesso B1

Figura 13 - Configuração do switch de AcessoB2

Figura 10 - Configuração do switch de AcessoA1

7- Campus A/Campus B:

O campus A conta com um dispositivo (pc-

Gerência) que tem acesso à interface gráfica via
web da ferramenta de monitoramento de rede
(Zabbix), esse é o único dispositivo que tem
permissão para acessar, onde somente ele
também tem acesso à interface gráfica do pfSense
(Firewall). De acordo com o que foi conversado
com o professor, nossa topologia interna está
dividida entre 3 vlans, vlan 10 de gerência da
rede, vlan 20 do campus A e vlan 30 do campus
B. Para realizar a conexão entre as vlans foi
utilizado o comando “Enable ipforwarding”.
Figura 11 - Configuração do switch de AcessoA2

Os protocolos utilizados nas áreas citadas foram

os seguintes:

1- FTP: File Transfer Protocol, é um protocolo de

transferência de arquivos. Para realizar o acesso
de forma visual foi utilizado o software Filezilla,
onde é acessado os servidores FTP na nuvem e na
DMZ.
 172.24.30.30/24. Isso mostra a conectividade entre os
HTTP/HTTPS: Esse protocolo é utilizado para dispositivos da intranet.
navegação na internet, nesse projeto todos os PCs
da intranet tem permissão para acessar páginas
web via protocolo HTTPS, seguindo as políticas
de segurança adotadas.

2- SNMP: Esse protocolo foi utilizado para a parte Figura 16 - Protocolo ICMP entre a rede INTRANET e a INTERNET

de gerência e monitoramento da rede. Dessa

forma, os dispositivos que podem ser gerenciados
estão com o protocolo SNMPv3, pois dessa
maneira eles podem ser descobertos, gerenciados
e adicionados ao mapa no Zabbix.
3- OSPF: Esse protocolo é responsável por todo o
roteamento da rede, foi criado somente a área 0
para atender toda a rede.
Ping do PC3 (dispositivo que está na vlan 20 no
campus A) para o ip 8.8.8.8, mostrando que existe a
conectividade entre os dispositivos que estão na rede
INTRANET conseguem acessar a internet., tanto de
campus A quanto do campus B.

Figura 17 - Protocolo ICMP da rede INTRANET para a DMZ e para

o Data Center

Essa tentativa de ping não funciona devido ao

bloqueio no firewall por conta das regras de segurança
Figura 14 - Topologia Completa adotadas no projeto.

- Testes de conectividade

Figura 15 - Protocolo ICMP entre a rede INTRANET

Ping do PC3 (dispositivo que está na vlan 20 no

campus A) para o ip 172.24.20.20/24 e para o ip Figura 18 - Protocolo ICMP do PC-Gerência para o Data Center
 Por ser um dispositivo que está em uma vlan de
gerência (PC-Gerência na vlan com tag 10), esse
dispositivo possui regras diferentes quando comparadas
aos dispositivos das vlans 20 e 30. Isso pode ser visto
quando comparar as figuras 9 e 10, onde mostra que
somente o PC-Gerencia consegue pingar o IP do Data
Center.
Figura 19 - Protocolo ICMP entre DMZ e o Data Center
Figura 20 - Protocolo ICMP entre DMZ e a INTRANET
As figuras acima (11 e 12) mostram que a DMZ
não possui uma conectividade com a rede INTRANET e
nem com o Data Center devido às regras criadas no
Firewall, visando uma maior segurança para projeto.
Figura 21 - Protocolo ICMP entre a DMZ para a INTERNET
A figura 13 mostra que existe uma conectividade
entre a DMZ e a internet, pois a DMZ é uma área pública
para usuários externos, mas inacessível para usuários
internos. Isso acontece pois é necessário que essa área da
DMZ seja acessível por dispositivos externos, e
inacessível para dispositivos internos, pois visa
proporcionar uma maior segurança para usuários da rede
LAN interna.
Atividade nº2:
1 – Instalação servidor Zabbix: O Zabbix é uma
importante ferramenta para o monitoramento da
infraestrutura de rede, sua utilização pode se dar por meio
da appliance do servidor fornecida no próprio site da
empresa, por meio da instalação manual do servidor em
uma máquina Linux ou até então por meio da instalação
via Docker. A opção escolhida foi a instalação vis
Docker, onde são utilizadas imagens do Zabbix Docker e
são instaladas em um dispositivo Ubuntu. As imagens à
serem baixadas que viabilizam o acesso à interface
gráfica de configuração e monitoramento do Zabbix são
a mysql e server-mysql, o banco de dados relacional que
permite o acesso aos dados armazenados e coletados é o
da imagem web-nginx-mysql, servidor web ningx que
recebe e responde as requisições HTTP e HTTPS, o java-
gateway é processo que roda em background para coletar
os dados de um host e por último a imagem zabbix-agent,
que é o agente Zabbix que coleta a métrica dos hosts.
As imagens a seguir, que foram tiradas do site da
referência [3], mostram quais foram os comandos
utilizados na linha de comando do dispositivo Ubuntu.
Figura 22 – Instalação o serviço Docker
Figura 23 – Imagens do Zabbix Docker do repositório online
2 – Descoberta no servidor Zabbix:
 Para que os dispositivos da rede sejam
descobertos pelo servidor Zabbix, foi configurado o
protocol SNMPv3.
Figura 24 – Configurção do protocolo SNMPv3 nos VyOS
~ # set service snmp listen-address <Endereço IP>:
Define o endereço IP em que o serviço SNMP será
configurado para ouvir.
~ # set service snmp location UNB: Define a localização
da rede ou dispositivo SNMP.
~ # set service snmp v3 engineid <id>: Define o ID do
mecanismo SNMPv3. O ID do mecanismo é usado para
identificar exclusivamente cada agente SNMPv3.
~ # set service snmp v3 view snmpview1 oid 1: Cria uma
visualização SNMPv3 chamada “snmpview1” que
permite acesso somente à OID (Object Identifier) 1. Isso
permite restringir o acesso SNMP a um subconjunto
específico de informações.
~ # set service snmp v3 group vyos-routers mode rw:
Define o grupo SNMPv3 “vyos-routers” no modo de
leitura e gravação (read-write).
~ # set service snmp v3 group vyos-routers seclevel priv:
Define o nível de segurança SNMPv3 do grupo “vyos-
routers” como privacidade (priv).
~ # set service snmp v3 group vyos-routers view
snmpview1: Associa a visualização SNMPv3
“snmpview1” ao grupo “vyos-routers”.
~ # set service snmp v3 user vyos auth plaintext-
password grs12345: Cria um usuário SNMPv3 chamado
“vyos” com autenticação baseada em senha (plaintext)
usando a senha “grs12345”.
~ # set service snmp v3 user vyos auth type ‘sha’: Define
o tipo de autenticação do usuário “vyos” como SHA.
~ # set service snmp v3 user vyos group vyos-routers:
Associa o usuário SNMPv3 “vyos” ao grupo “vyos-
routers”.
~ # set service snmp v3 user vyos privacy plaintext-
password grs12345: Define a senha de privacidade
(criptografia) do usuário “vyos” como “grs12345”.
~ # set service snmp v3 user vyos privacy type ‘aes’:
Define o tipo de privacidade do usuário “vyos” como
AES.
Figura 25 – Configuração do protocolo SNMPv3 nos switches
~ #configure snmpv3 add user exos-sw authentication
sha grs12345 privacy aes grs12345: Este comando
adiciona um usuário SNMPv3 chamado “exos-sw” com
autenticação SHA e privacidade AES. A senha de
autenticação é definida como “grs12345” e a senha de
privacidade é definida como “grs12345”.
~ #configure snmpv3 add group exos user exos-sw sec-
model usm: Este comando adiciona um grupo SNMPv3
chamado “exos” e associa o usuário “exos-sw” a esse
grupo. O modelo de segurança usado é o USM (User-
based Security Model).
~ #configure snmpv3 add access exos sec-model usm
sec-level priv read-view defaultAdminView write-view
defaultAdminView notify-view defaultAdminView: Este
comando adiciona uma regra de acesso chamada “exos”
para o modelo USM com nível de segurança privacidade
(priv). Essa regra de acesso permite acesso de leitura
(read-view), acesso de escrita (write-view) e notificações
(notify-view) usando a visualização padrão do
administrador (defaultAdminView).
~ #enable snmp access snmpv3: Este comando habilita o
acesso SNMPv3.
3 – Gráficos e Mapa no Zabbix:
 Como parte essencial de segurança dos dados e
dispositivos sensíveis da rede, o primeiro passo em todas
as interfaces é bloquear qualquer tráfego para o
Datacenter, para garantir que não haja nenhum acesso a
essa área.

1 – WAN

Para a interface da rede externa as regras foram

Figura 26 – Dashboard com gráficos e mapa da rede no Zabbix
Atividade nº3:
Para garantir uma melhor segurança para a rede
entre seus dados e dispositivos sensíveis, e até mesmo os
próprios usuários, foram adotadas regras de segurança ao
Firewall (pfSense) para filtragem dos tráfegos.
Figura 27 – Regras de Firewall da interface da WAN.
definidas de forma que só são aceitas requisições onde
inicialmente foram solicitadas pela rede interna,
garantindo a segurança contra o acesso de usuários
externos e mantendo o acesso à internet aos usuários
internos que necessitam dessa comunicação.
O tráfego com destino à DMZ é liberado, uma vez
que é uma área pública e segura da rede.
Todos os demais tráfegos são bloqueados.
2 – DMZ
O primeiro passo nessa interface foi bloquear
qualquer tráfego para dentro da INTRANET, uma vez
que a DMZ é uma zona de acesso público, evitando
que esse seja um ponto de acesso de usuários externos
à rede interna, mantendo a comunicação com a rede
externa apenas dos dados recebidos pela DMZ através
dos protocolos permitidos da rede interna.
Todos os demais tráfegos são liberados, permitindo
acesso público.

3 – Campus A / B

Figura 28 – Regras de Firewall da interface da DMZ.
Figura 29 – Regras de Firewall da interface do Campus A.
Figura 30 – Regras de Firewall da interface do Campus B.
Cada campus possui suas respectivas
VLANs de acesso (20 e 30), já a VLAN 10 se
refere à VLAN de gerenciamento, portanto
usuários nessa VLAN possuem acesso total com
o intuito de gerenciar a rede, sendo esse o único
meio de acesso ao Datacenter.
No caso das VLANs de acesso, os
tráfegos solicitados pelo roteiro do professor
foram unicamente liberados à DMZ nas portas
necessárias para VoIP, FTP e a porta específica
5201 do servidor TCP/UDP criado para fins de
experimento do roteiro. Todos os demais tráfegos
para à DMZ são bloqueados, evitando qualquer
tipo de vazamento indesejado ou brechas para
invasão.

4 – Datacenter

Figura 31 – Regras de Firewall da interface do Datacenter.

Por fim, a área mais sensível da rede conta com
uma total proteção contra qualquer acesso. Essa
 interface conta apenas com o tráfego do protocolo
SNMP na porta específica para que seja feita a
descoberta e mapeamento dos dispositivos na rede
junto do ICMP.

Para fins de experimento solicitados no roteiro foram

criados tráfegos VoIP, TCP, UDP e FTP entre as redes
INTRANET, NUVEM e DMZ, foram gerados tráfegos
tanto de saída quanto de entrada dessas áreas.
Para geração de tráfego VoIP foi utilizado o software
Linphone, que consiste no tráfego de voz entre
dispositivos através do protocolo SIP na porta 5060.
Para testar a conectividade TCP/UDP foi utilizado o
software IPERF3, onde foi possível criar um servidor
escutando as requisições do cliente na porta 5201.
Para a transferência de arquivos foi utilizado um
servidor FTP acessível por interface gráfica por meio do
software Filezilla, dessa forma foi possível o tráfego de
arquivos via protocolo FTP na porta 21. Figura 34 – Tráfego TCP/UDP DMZ - INTRANET.

Figura 35 – Captura tráfego TCP/UDP DMZ - INTRANET.

Figura 32 – Tráfego TCP/UDP INTRANET - DMZ.

Figura 36 – Tráfego VoIP INTRANET - DMZ.

Figura 33 – Captura tráfego TCP/UDP INTRANET - DMZ.

Figura 37 – Tráfego VoIP DMZ - INTRANET.

Figura 40 – Tráfego TCP/UDP INTRANET - NUVEM.

Figura 38 – Tráfego FTP INTRANET - DMZ.

Figura 41 – Captura tráfego TCP/UDP INTRANET - NUVEM.

Figura 39 – Tráfego FTP DMZ - INTRANET.

Figura 42 – Tráfego VoIP INTRANET - NUVEM.

 IV. CONCLUSÕES

Após a realização desse projeto foi possível entender,

Figura 43 – Tráfego FTP INTRANET - NUVEM.
em uma menor escala, o gerenciamento de uma rede real
bem como sua arquitetura e planejamento. Com as
ferramentas utilizadas foi possível criar, além de uma
rede concreta, um modelo prático de gerenciamento,
apontando os desafios reais da organização de uma rede.
Com os experimentos feitos durante o roteiro foi possível
analisar e entender os tráfegos dentro e fora da rede,
levando a resultados que nos permitiram compreender e
adotar políticas de segurança adequadas a este projeto.
Por fim, pode-se concluir que essa experiência contribuiu
para o aprimoramento do conhecimento sobre o
planejamento, configuração, gerenciamento e segurança
de redes.

Com auxílio do software Wireshark foi possível

analisar os tráfegos gerados em toda a rede; INTRANET,
NUVEM e DMZ. REFERÊNCIAS BIBLIOGRÁFICAS
[1] https://www.opservices.com.br/protocolos-de-rede/
Como mostrado nas Figuras 32 – 43 o tráfego de [2] https://www.fortinet.com/resources/cyberglossary/what-
rede se restringe obedecendo as regras de segurança is-dmz
adotadas ao Firewall, conforme era esperado. [3] https://techexpert.tips/pt-br/zabbix-pt-br/zabbix-
instalacao-docker-no-ubuntu-linux/
Para a rede INTRANET, nota-se que o tráfego [4]
para a internet é permitido, sendo possível enviar e
receber requisições, dessa forma o tráfego de TCP/UDP,
VoIP e FTP é permitido com sucesso, conforme
mostrado. Já em relação ao tráfego para a DMZ, as
requisições permitidas são apenas as específicas nas
portas liberadas para os protocolos utilizados de VoIP e
FTP, além da porta permitida para teste da conectividade
TCP/UDP.

Para a rede da DMZ nota-se que o tráfego para a

internet é liberado, por se tratar de uma zona pública, e
que todo o tráfego com destino a INTRANET é
bloqueado, exceto o recebimento das requisições
permitidas com origem da própria INTRANET. Dessa
maneira, os testes comprovam as regras adotadas ao
Firewall, onde foi mostrado que nenhuma requisição com
destino à INTRANET obteve sucesso.

Por fim, o tráfego na nuvem é gerenciado de forma

que só consiga transmitir pacotes nas quais sejam
requisições com origem da própria INTRANET. Dessa
maneira, os testes comprovaram corretamente as regras
adotadas, onde o tráfego da NUVEM obteve sucesso
apenas nos protocolos em resposta às requisições feitas
por usuário da INTRANET.