Jfonseca 2016 PDF

E S C O L A S U P E R I O R D E T E C N O L O G I A E G E S T O
Implementao de autenticao 802.1.x e IPv6 na rede

cablada da ESTG
DESIGNAO DO MESTRADO
Redes e Servios de Comunicao
AUTOR
Jorge Gonalo Monteiro da Fonseca
O R I E N T A D O R ( E S ) Professor Doutor Antnio Alberto Santos Pinto
ANO
2016
Este trabalho no inclui as crticas e sugestes feitas pelo Jri
www.estgf.ipp.pt
Implementacao de autenticacao 802.1.x e IPv6 na
rede cablada da ESTG
Jorge Goncalo Monteiro da Fonseca

Mestrado em Redes e Servicos de Comunicacao
ESTG-IPP
8010016@estg.ipp.pt
Orientador: Antonio Alberto Santos Pinto
25 de Novembro de 2016
ii
Agradecimentos
Agradeco a todos os que me apoiaram neste percurso, dando-me forca e

motivac
ao para concluir este projeto.
Ao meu orientador, Professor Doutor Antonio Alberto dos Santos Pinto,

pelo seu apoio, incentivo, disponibilidade e dedicacao que teve ao longo da
execucao deste trabalho.
Agradeco `
a Escola Superior de Tecnologia e Gestao por me ter proporci-
onado as condic
oes necess
arias `
a realizacao e implementacao deste trabalho.
A` minha esposa Amelia, pela sua compreensao, apoio e incentivo. Aos

meus filhos Miguel e Leonor pela ternura sempre manifestada apesar da falta
de atenc
ao e ausencia.
Agradeco de forma muito especial e saudosa aos meus pais, pela educacao
que me deram e pelo exemplo de vida que foram. A eles dedico de forma
muito especial este trabalho.
iii
iv
Resumo
A atual rede da ESTG opera em IPv4 e so tem suporte para autenticacao

em ligacoes `
a rede sem fios eduroam. Ligacoes à rede por cabo nao sao
autenticadas e nao ha ligac
ao `
a Internet por IPv6. O objetivo proposto neste
projeto foi o da avaliacao da viabilidade de implementacao de mecanismos
de autenticacao para a rede cablada em conjunto com a migracao da rede
para IPv6.
O IPv6 tem diferencas significativas relativamente ao IPv4. Uma vez que
o protocolo IPv6 n ao e compatvel com IPv4, e necessaria a implementacao
de mecanismos de transic ao para a IPv6. Existem varios mecanismos de-
senvolvidos especificamente para suportar esta transicao e que permitem a
coexistencia das duas vers oes do IP.
A soluc
ao encontrada pode ser dividida em duas partes. Uma parte que
consiste na implementac ao de autenticacao, autorizacao e criacao de uma
guest-vlan na rede cablada . A outra parte que consiste na configuracao
dos servicos associados ao IPv6, de que sao exemplo a configuracao de IP, o
roteamento, o servico de DNS e filtragem de trafego e o registo de atividade
na rede.
A implementac ao de 802.1X permitiu dotar a rede da ESTG de mecanis-
mos de autenticac ao e autorizacao na rede cablada . Na solucao proposta,
o servidor de autenticac ao tem uma AD como backend para autenticacao.
Foram analisados os v arios equipamentos e constatou-se que todos supor-
tam o referido protocolo. O servidor de autenticacao implementado foi o
FreeRadius que suporta os protocolos de autenticacao mais comuns, que foi
configurado com backend de autenticacao numa Active Directory 2012 R2.
Foi ainda implementada uma guest-vlan onde os utilizadores nao autentica-
dos sao colocados.
A implementac ao de IPv6 na rede da ESTG implicou algumas alteracoes
de servicos existentes e a implementacao de novos. O servico de DNS foi
reconfigurado para aceitar e responder a querys IPv6. Foi implementado o
servico de DHCPv6. Os servicos de roteamento e filtragem de trafego fo-
ram implementados num firewall. Por u ltimo foram tambem implementados
mecanismos de registo de atividade.
v
vi
Abstract
The current ESTG network only operates with IPv4 and only supports
authenticated connections on the eduroam wireless network. Wired network
connections are not authenticated and there is no IPv6 Internet connection.
The objective of this project consists on evaluating the feasibility of imple-
menting authentication mechanisms for the wired network in conjunction
with the implementation of IPv6.
IPv6 has significant differences when compared to IPv4. IPv6 protocol
is not compatible with IPv4, requiring the implementation of transition
mechanisms. There are several mechanisms developed specifically to support
this transition and to enable the coexistence of both IPv4 and IPv6.
The proposed solution can be divided into two main parts. The first
one relates to the implementation of the authentication, authorization of
equipment connected to the wired network and the implementation of a
guest-vlan. The other consists in configuring IPv6 services, such as address
configuration, routing, DNS service, traffic filtering and network activity
logging.
The 802.1X implementation enables the ESTG network to provide authen-
tication and authorization mechanisms on to the wired network. In the pro-
posed solution, the authentication server has an AD as an authentication
backend. The various equipments were analyzed and it was verified that all
supported the referred protocol. FreeRadius was the selected authentication
server. It supports the most common authentication protocols and was con-
figured with an Active Directory 2012 R2 as the authentication backend. A
guest-vlan was also implemented, where unauthenticated users are placed.
The IPv6 implementation at the ESTG network entailed both some chan-
ges on existing services and the implementation of new ones. The DNS
service has been reconfigured to accept and respond to IPv6 requests. The
DHCPv6 service was implemented. Traffic routing and filtering services
have been implemented in a firewall. Finally, activity logging mechanisms
were also implemented.
vii
viii
Conte
udo
1 Introdu
cao 1
1.1 Objetivos do trabalho . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Resultados relevantes . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Estrutura do relat
orio . . . . . . . . . . . . . . . . . . . . . . 3
2 Controlo de acesso ` a rede 5

2.1 RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Autenticac
ao baseada em MAC Address . . . . . . . . . . . . 7
2.3 Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4 Captive Portal . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.1 Implementac ao . . . . . . . . . . . . . . . . . . . . . . 10
2.4.2 Limitac oes . . . . . . . . . . . . . . . . . . . . . . . . 11
2.5 802.1x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.6 Analise comparativa . . . . . . . . . . . . . . . . . . . . . . . 16
2.7 Conclus ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3 Protocolo Internet 19
3.1 IP vers
ao 4 (IPv4) . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.1 Enderecamento . . . . . . . . . . . . . . . . . . . . . . 20
3.1.2 Limitacoes do IPv4 . . . . . . . . . . . . . . . . . . . . 21
3.2 IP vers
ao 6 (IPv6) . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.1 Enderecamento . . . . . . . . . . . . . . . . . . . . . . 24
3.2.2 Novas funcionalidades . . . . . . . . . . . . . . . . . . 25
3.2.3 Transicao e Interoperabilidade IPv4/IPv6 . . . . . . . 26
3.3 Conclusao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4 Rede ESTG/IPv6 31
4.1 Situac
ao atual . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2 Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.3 Proposta de solucao . . . . . . . . . . . . . . . . . . . . . . . 34
4.3.1 802.1X . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.3.2 IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.4 Conclus ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
ix

CONTEUDO
CONTEUDO
5 Avalia
cao do trabalho 43
5.1 Soluc
ao Final . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.2 Testes efetuados . . . . . . . . . . . . . . . . . . . . . . . . . 53
6 Conclus
ao 59
6.1 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.2 Trabalho futuro . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Anexos 69
A Configura
c
ao do tayga 71
B Configura
cao do Authenticator 73
C Configura
cao dos Clientes 75
C.1 Windows 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
C.2 Fedora 24 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
C.3 MacOs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
D Configura
cao do servidor de autentica
cao 85
E Captive Portal 93
F Configura
cao da pfsense 95
F.1 DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
F.2 Regras de firewall . . . . . . . . . . . . . . . . . . . . . . . . . 95
G Plano de Endere
camento IPv6 97
x
Lista de Figuras
2.1 Autenticac
ao com RADIUS . . . . . . . . . . . . . . . . . . . 6
2.2 Autenticac
ao por endereco MAC . . . . . . . . . . . . . . . . 7
2.3 Autenticac
ao com Kerberos . . . . . . . . . . . . . . . . . . . 8
2.4 Estrutura de mensagem do Kerberos . . . . . . . . . . . . . . 9
2.5 Exemplo de autenticac
ao por Captive Portal . . . . . . . . . 10
2.6 Esquema funcional 802.1x . . . . . . . . . . . . . . . . . . . . 11
2.7 Componentes do 802.1x . . . . . . . . . . . . . . . . . . . . . 12
2.8 Autenticac
ao em 802.1X com RADIUS . . . . . . . . . . . . . 16
3.1 Comparac
ao entre cabecalhos IPv4 e IPv6 . . . . . . . . . . . 25
4.1 Diagrama atual da rede ESTG . . . . . . . . . . . . . . . . . 33

4.2 Diagrama funcional da proposta de solucao . . . . . . . . . . 34
4.3 Elementos da implementacao de 802.1X na ESTG . . . . . . 36
5.1 Esquema funcional do ambiente de testes . . . . . . . . . . . 44

5.2 Diagrama final da rede ESTG com suporte IPv6/802.1X . . 45
5.3 Enderecamento das interfaces da Pfsense . . . . . . . . . . . . 50
5.4 Configurac
ao DHCPv6 na pfsense . . . . . . . . . . . . . . . . 50
5.5 Configurac
ao do RADVD para uma rede local . . . . . . . . . 51
5.6 Aliases na pfsense . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.7 Regras de firewall na pfsense . . . . . . . . . . . . . . . . . . 52
5.8 Configurac
ao de Logs remotos na Pfsense . . . . . . . . . . . 53
5.9 Registo de atribuic
ao de endereco IPv6 . . . . . . . . . . . . . 56
5.10 Logs da firewall Pfsense . . . . . . . . . . . . . . . . . . . . . 57
C.1 Servicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
C.2 Network Center . . . . . . . . . . . . . . . . . . . . . . . . . . 76
C.3 Propriedades da placa de rede . . . . . . . . . . . . . . . . . . 77
C.4 Propriedades EAP . . . . . . . . . . . . . . . . . . . . . . . . 78
C.5 Propriedades do EAP MSCHAPv2 . . . . . . . . . . . . . . . 79
C.6 Propriedades avancadas da autenticacao . . . . . . . . . . . . 80
C.7 Janela de autenticacao 802.1X . . . . . . . . . . . . . . . . . . 81
C.8 Network Manager . . . . . . . . . . . . . . . . . . . . . . . . . 81
xi
LISTA DE FIGURAS LISTA DE FIGURAS
C.9 Janela de configuracao 802.1X . . . . . . . . . . . . . . . . . . 82

C.10 Pedido de credenciais . . . . . . . . . . . . . . . . . . . . . . . 82
C.11 Introduzir credenciais . . . . . . . . . . . . . . . . . . . . . . 83
C.12 Apresentac
ao do certificado . . . . . . . . . . . . . . . . . . . 83
C.13 Aceitac
ao do certificado . . . . . . . . . . . . . . . . . . . . . 84
C.14 Propriedades da rede . . . . . . . . . . . . . . . . . . . . . . . 84
E.1 Captive Portal com instrucoes de configuracao . . . . . . . . 93
F.1 Configurac
ao DHCPv6 na pfsense . . . . . . . . . . . . . . . . 95
F.2 Aliases na pfsense . . . . . . . . . . . . . . . . . . . . . . . . . 95
F.3 Regras de firewall na pfsense . . . . . . . . . . . . . . . . . . 96
xii
Lista de Tabelas
2.1 Metodos de autenticac

ao EAP . . . . . . . . . . . . . . . . . 14
2.2 Tecnologias de controlo de acesso a rede . . . . . . . . . . . . 17
3.1 Classes de enderecamento IPv4 . . . . . . . . . . . . . . . . . 20

3.2 Enderecamento privado . . . . . . . . . . . . . . . . . . . . . 21
4.1 VLANs em uso . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.2 Servicos de rede permitidos . . . . . . . . . . . . . . . . . . . 39
5.1 Esquema de enderecamento IPv6 . . . . . . . . . . . . . . . . 49
G.1 Plano de enderecamento IPv6 . . . . . . . . . . . . . . . . . . 98
xiii
LISTA DE TABELAS LISTA DE TABELAS
xiv
Lista de Listagens
5.1 Resoluc
ao de nomes utilizando DNS64 . . . . . . . . . . . . . 44
5.2 Passos para a configuracao de autenticacao num switch HP
Proliant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.3 Script para autenticac ao 802.1X em Fedora . . . . . . . . . . 47
5.4 Ficheiro de zona do BIND . . . . . . . . . . . . . . . . . . . . 51
5.5 Teste de autenticac ao utilizando NTLM . . . . . . . . . . . . 53
5.6 Teste de autenticac ao utilizando radtest . . . . . . . . . . . . 54
5.7 Comandos para visualizacao do estado do authenticator . . . 54
5.8 Registo com sucesso de autenticacao no RADIUS . . . . . . . 55
5.9 Teste de resoluc
ao de nomes IPv6 . . . . . . . . . . . . . . . . 56
5.10 Registo de atividade no Rsyslog . . . . . . . . . . . . . . . . . 57
A.1 Ficheiro de configurac ao do tayga . . . . . . . . . . . . . . . . 71
A.2 Script de inicializac
ao do tayga . . . . . . . . . . . . . . . . . 71
B.1 Configurac
ao do switch HP Procurve . . . . . . . . . . . . . . 73
D.1 Ficheiro de configurac ao radiusd.conf . . . . . . . . . . . . . . 85
D.2 Ficheiro de configurac ao ldap.conf . . . . . . . . . . . . . . . 86
D.3 Ficheiro de configurac ao sites-enabled/default mschap . . . . 88
D.4 Ficheiro de configurac ao do sites-enabled/default . . . . . . . 88
D.5 Ficheiro de configurac ao sites-enabled/inner-tunnel . . . . . . 90
D.6 Ficheiro de configurac ao clients.conf . . . . . . . . . . . . . . 91
xv
LISTA DE LISTAGENS LISTA DE LISTAGENS
xvi
Lista de Acr
onimos
DoS: Denial of Service

IDS: Intrusion Detection System
IPS: Intrusion Prevention System
LDAP: Lightweight Directory Access Protocol
VLAN: Virtual LAN
USB: Universal Serial Bus
DHCP: Dynamic Host Configuration Protocol
QoS: Quality of Service
IPv4: Internet Protocol version 4
IPv6: Internet Protocol version 6
IP: Internet Protocol
SEND: Secure Neighbor Discovery
IEEE: Institute of Electrical and Electronics Engineers
OSI: Open Systems Interconnection
RADIUS: Remote Authentication Dial-In User Service
EAP: Extensible Authentication Protocol
MIT: Massachusetts Institute of Technology
RFC: Request for Comments
KDC: Key Distribution Center
DES: data encryption standard
AAA: Authentication, Authorization, and Accounting
NAS: Network Access Server
PPP: Point-to-Point Protocol
PAP: Password Authentication Protocol
CHAP: Challenge-Handshake Authentication Protocol
DHCPv6: Dynamic Host Configuration Protocol version 6
DHCP: Dynamic Host Configuration Protocol
DUID: DHCP Unique Identifier
DNS: Domain Name Service
ARPANET: Advanced Research Projects Agency Network
NAT: Network Address Translation
ISP: Internet Service Provider
IPSec: Internet Protocol Security
xvii
xviii
LISTA DE ACRONIMOS
TOS: Type of Service

TTL: Time to live
VOIP: Voice over Internet Protocol
IPng: IP next generation
IETF: Internet Engineering Task Force
AH: Authentication Header
ESP: Encrypted Security Payload
ND: Neighbor Discovery Protocol
SLAAC: Stateless address autoconfiguration
GRE: Generic Routing Encapsulation
ISATAP: Intrasite Automatic Tunnel Addressing Protocol
SIIT: Stateless IP/ICMP Translator
NAT-PT: Network Address Translation/Protocol Translation
TRT: Transport Relay Translator
TCP: Transmission Control Protocol
UDP: User Datagram Protocol
DSL: Digital subscriber line
ICANN: Internet Corporation for Assigned Names and Numbers
DNSSEC: Domain Name System Security Extensions
TSIG: TTransaction SIGnature
AD: Active Directory
AD DS: Active Directory Domain Services
SSL: Secure Sockets Layer
TLS: Transport Layer Security
RELP: Reliable Event Logging Protocol
ASF: Alert Standard Forum
GIRA: Gest ao Integrada de Recursos e Aplicacoes
IPP: Instituto Politecnico do Porto
TGT: Ticket-granting Tickets
TGS: Ticket-granting Service
MITM: man-in-the-middle
LEAP: Lightweight Extensible Authentication Protocol
OTP: One-Time Password
EAP-TLS: EAP-Transport Layer Security
EAP-TTLS: EAP-Tunneled Transport Layer Security
PEAP: Protected Extensible Authentication Protocol
MS-CHAP: Microsoft Challenge Authentication Protocol
WEP: Wired Equivalent Privacy
EAP-GTC: EAP Generic Token Card
EAPoL: Extensible Authentication Protocol (EAP) over LAN
CIDR: Classless Inter-Domain Routing
FTP: File Transfer Protocol
SIP: Session Initiation Protocol
IHL: Internet Header Length
xix
LISTA DE ACRONIMOS
IAB: Internet Architecture Board

EUI: Extended Unique Identifier
NTLM: Windows Challenge/Response
DUID: DHCP Unique Identifier
RA: Router Advertisements
RADVD: Router Advertisement Daemon
BIND: Berkeley Internet Name Domain
SP: Servicos da Presidencia
DMZ: Demilitarized Zone
URL: Uniform Resource Locator
xx
LISTA DE ACRONIMOS
Captulo 1
Introdu
c
ao
No mundo tecnol ogico em que vivemos, os sistemas informaticos e as redes

de computadores est ao presentes em todos os setores da sociedade. E um
pilar fundamental do desenvolvimento economico e, como tal, um potencial
alvo de ataques por parte de utilizadores mal intencionados que procuram
benefcios proprios.
A seguranca inform atica em redes de computadores e por isso uma
questao crtica. A protec
ao dos sistemas informaticos, por si so, nao e sufi-
ciente. Toda a infraestrutura de rede, routers, switchs, servidores e servicos
que suportam tais sistemas n ao pode falhar.
Os utilizadores acedem a v arias redes p ublicas, em varios locais, utili-
zando v arias tecnologias de acesso, usando varios dispositivos com varios
sistemas operativos e aplicac oes. Um administrador de uma rede nao con-
segue saber qual foi a rede ` a qual um dispositivo esteve ligado antes de
aceder à sua rede. O dispositivo pode estar infetado com vrus, malware ou
outras aplicacoes maliciosas, que podem comprometer a seguranca da rede,
infetando outros sistemas ou participando em atividades nao autorizadas.
Ataques do tipo Denial of Service (DoS), packet sniffing, ARP spoofing e
outros podem ocorrer, podendo ter como consequencia o comprometimento
de sistemas ou o mau funcionamento da rede informatica da instituicao.
A possibilidade de surgirem ataques ou utilizacoes abusivas com origem na
instituic
ao, a servicos externos à instituicao, e tambem um problema que
assume particular gravidade. Os utilizadores ligam-se cada vez mais às
redes institucionais e corporativas utilizando os seus proprios dispositivos.
Existem mecanismos, tais como firewalls, Intrusion Detection System
(IDS) e Intrusion Prevention System (IPS) que tem como objetivo a detecao
e prevencao de ataques inform aticos e de outras atividades maliciosas. E im-
portante garantir que quando estes ataques ocorram, se consegue identificar
o seu autor.
A atual estrutura de rede da ESTG permite que qualquer utilizador se
ligue à rede cablada de qualquer laboratorio ou gabinete sem que exista al-
1
2 Introducao
gum tipo de controlo de acesso. Os computadores da instituicao ao servico

dos estudantes obrigam a uma autenticacao via Lightweight Directory Ac-
cess Protocol (LDAP). A rede esta segmentada em VLANs, uma por labo-
ratorio, Centro de Investigacao e servicos, com permissoes de acesso à rede
distintas de acordo com as necessidades de cada uma.
Torna-se necess aria a implementacao de mecanismos centralizados de
autorizacao, autenticacao e de controlo de acesso à rede que impecam que
um utilizador n ao autorizado aceda a recursos da infraestrutura de rede
cablada da ESTG. Esse mecanismo devera ainda permitir o registo de toda
a atividade de um utilizador, para que desta forma se possa identificar o
autor de qualquer atividade que possa ser considerada abusiva, nociva ou
ilegal.
A rede da ESTG esta implementada em Internet Protocol version 4
(IPv4). O protocolo IPv4 apresenta varias limitacoes, tais como a exaustao
dos enderecos p ublicos disponveis, obrigatoriedade de configuracao Inter-
net Protocol (IP) manual ou por Dynamic Host Configuration Protocol
(DHCP), inexistencia de mecanismos de seguranca nativos, e um suporte
Quality of Service (QoS) limitado.
O protocolo Internet Protocol version 6 (IPv6) foi criado com o objetivo
de substituir o IPv4, resolvendo muitos dos seus problemas, e permitindo
mobilidade, autoconfiguracao e aumento da sua extensibilidade. Ao nvel da
seguranca, o protocolo IPv6 introduz varias melhorias. O protocolo IPSec,
que fornece confidencialidade, autenticacao e integridade dos dados, esta
j
a integrado no IPv6. IPv6 permite tambem uma identificacao de equipa-
mentos na rede mais segura, utilizando o protocolo Secure Neighbor Disco-
very (SEND). O protocolo SEND dificulta a utilizacao de ataques do tipo
ARP spoofing.
Na ESTG ainda n ao foi feito nenhum estudo relativo à implementacao
de IPv6 na sua rede, muito embora ja se sintam algumas das limitacoes do
IPv4, nomeadamente no que respeita à exaustao dos enderecos IP p ublicos
existentes. Cada vez mais ocorre a necessidade de configuracao de novos
servicos para serem utilizados tanto em contexto academico como de inves-
tigac
ao, servicos estes que necessitam de ser acedidos do exterior. Com o
numero reduzido de IPs p ublicos disponveis para a ESTG, nem sempre se
consegue atender ` as solicitacoes recebidas.
1.1 Objetivos do trabalho

O objetivo deste trabalho e o de avaliar, por meio da implementacao de um
prot
otipo, da necessidade, operacionalidade e viabilidade da implementacao
de mecanismos de autenticacao para a rede cablada (802.1X), em conjunto
com a migracao da rede para IPv6.
3 Introducao
1.2 Resultados relevantes

O prototipo a implementar dever
a suportar:
1. Autentica cao: Os utilizadores para terem acesso à rede da ESTG

por cabo dever ao fornecer as suas credenciais, como ja o fazem na
rede sem fios.
2. Autoriza c
ao: Para que seja concedido acesso à rede cablada a um
utilizador, o mesmo devera ter permissao para tal.
3. Guest-Vlan: Dever a existir uma Guest-Vlan com redirecionamento

para p
agina com instruc
oes de configuracao.
4. Configura c
ao de IP: A configuracao de enderecamento IP (IPv6)
dever
a ocorrer de forma automatica.
5. Roteamento: O tr afego com destino a redes IPv4 e IPv6 devera ser

corretamente encaminhado.
6. DNS: A resoluc
ao de nomes IPV4 e IPv6 devera estar devidamente
configurada.
7. Filtragem de tr afego: Deverao estar definidas um conjunto de re-

gras para eliminar ou aceitar o trafego nas ligacao em rede.
8. Registo de atividade: A atividade dos utilizadores na rede devera

ficar registada de forma centralizada.
1.3 Estrutura do relat

orio
O relat orio est
a organizado em captulos. No capitulo 2 abordam-se varias
tecnologias de controlo de acesso è rede. O funcionamento de cada um
delas e descrito de uma forma geral identificando as suas principais carac-
tersticas. No final deste capitulo e efetuada uma analise comparativa entre
estas tecnologias. No capitulo 3 s ao apresentados os protocolos IPv4 e IPv6,
identificando-se as limitacoes e vantagens de cada um deles. Sao tambem
abordados as metodologias para a transicao de IPv4 para IPv6. No capitulo
4 e apresentada a solucao implementada, incluindo os servicos implementa-
dos e o desenho funcional da solucao. No capitulo 5 e efetuada a avaliacao
do trabalho que foi implementado, onde se poderao ver os resultados dos
testes efetuados e do registo da atividade da rede. O capitulo 6 apresenta
as conclus oes do trabalho efetuado.
4 Introducao
Captulo 2
Controlo de acesso `
a rede
Numa era de expans ao tecnol ogica como a que vivemos, os computadores e

as redes inform aticas desempenham um papel crucial. A tecnologia passou
a ser uma parte integrante dos modelos de negocio das organizacoes, permi-
tindo a aumento do nvel de eficiencia das mesmas. Sao in umeros os servicos
disponibilizados pelas redes de computadores, tais como armazenamento de
dados, servicos de impress ao, servicos de autenticacao, capacidade de pro-
cessamento de dados. Estes servicos sao passveis de ser alvo de ataques
informaticos com diferentes objetivos, que podem ser desde o roubo de in-
formacao, a utilizac
ao indevida dos recursos ou simplesmente a negacao dos
servicos aos utilizadores. Nesta otica, a seguranca informatica apresenta-se,
cada vez mais,como uma area de grande importancia.
Ha instituic
oes que n ao tem implementados mecanismos de seguranca
que efetuem o controlo de acesso quando um computador de um utilizador
se liga a uma rede cablada. Normalmente quando um computador de um
qualquer utilizador se liga ` a rede, este recebe um endereco IP de um servidor
DHCP. Nesta fase estes computadores nao estao identificados nem autenti-
cados na rede e podem efetuar atividades maliciosas, que podem ser causadas
por maquinas comprometidas ou por ataques informaticos, podendo ate ser
complexas dependendo do conhecimento do hacker [39].
Os mecanismos de controlo de acesso à rede permitem monitorizar o
acesso ` a rede inform atica de uma organizacao, implementando seguranca
no equipamento terminal. Os dispositivos nao sao autorizados a ligarem-se
à rede a n ao ser que cumpram uma serie de requisitos pre-definidos que
sao implementados pelos equipamentos de rede responsaveis pelo controlo
de acesso ` a rede. Em infraestruturas onde existe um grande n umero de
utilizadores, e em que muitos deles acedem à rede utilizando os seus proprios
dispositivos, a existencia de mecanismos de controlo de acesso à rede revela-
se de grande import ancia.
Existem diversas tecnologias que podem ser utilizar para implementar
o controlo de acesso ` a rede. Dependendo do grau de seguranca pretendido,
5
6 Controlo de acesso à rede
Cliente RADIUS
HUB NAS Servidor

RADIUS
1 4
2 5
3
Cliente
Figura 2.1: Autenticacao com RADIUS
dos equipamentos a utilizar, da complexidade de configuracao, etc, estes

podem ser mais ou menos indicados para a solucao que se pretende configu-
rar. Algumas dessas solucoes, bem como uma analise comparativa destas, e
apresentada de seguida.
2.1 RADIUS
O protocolo Remote Authentication Dial-In User Service (RADIUS) e defi-
nido pelo RFC 2865 [69] e permite a gestao centralizada de Authentication,
Authorization, and Accounting (AAA) para os utilizadores que se autenti-
quem para usarem um servico de rede. Trata-se de um protocolo cliente-
servidor que suporta diversos mecanismos de autenticacao, funcionando na
camada de aplicacao do modelo Open Systems Interconnection (OSI) e pode
funcionar tanto em Transmission Control Protocol (TCP) como em User
Datagram Protocol (UDP). A operacao sobre TCP e mais comum pois
garante a retransmiss ao em caso de perda de pacotes. Os network access
server (NAS) normalmente contem clientes RADIUS que comunicam com
o servidor RADIUS. O servidor RADIUS e, normalmente, um processo que
corre numa m aquina Windows ou Linux [4].
Na Figura 2.1 podemos ver a troca de mensagens que ocorre quando um
utilizador se autentica. Esta troca compreende 5 passos.
1. O utilizador inicia autenticacao Point-to-Point Protocol (PPP) com o

NAS.
2. O NAS solicita o nome de utilizador e senha (se se utilizar Password

Authentication Protocol (PAP)) ou um valor de desafio (se se utilizar
Challenge-Handshake Authentication Protocol (CHAP)).
3. O utilizador fornece a informacao solicitada pelo NAS.
4. O cliente RADIUS (re)envia a informacao do utilizador para o servidor

RADIUS.
Figura 2.2: Autenticacao por endereco MAC

2 MAC do cliente enviado
1 Pedido de associao como RADIUS Request
4 Resposta ao pedido de
3 RADIUS Accept
associao (Aceite)
Cliente RADIUS
Switch
5. O servidor RADIUS responde com aceitacao, rejeicao ou com novo

desafio.
6. O cliente RADIUS age de acordo com a resposta.
Atualmente, a utilizacao de servidores RADIUS surge muito frequente-

mente em conjunto com outras tecnologias de autenticacao. Exemplos de
tal sao a autenticac
ao por endereco MAC, autenticacao com Captive portal
e autenticac
ao com 802.1X.
2.2 Autentica
c
ao baseada em MAC Address
A autenticacao baseada em MAC address autentica um dispositivo utili-
zando o endereco fsico de origem das tramas recebidas. Existem duas for-
mas principais de efetuar este tipo de autenticacao. Atraves do switch, ou
de forma centralizada utilizando um servidor RADIUS [12].
Quando efetuada localmente no switch, o equipamento e configurado
para permitir a ligac
ao de equipamentos em que o MAC address esteja regis-
tado no mesmo. Desta forma teremos que configurar em cada equipamento
de rede quais os equipamentos que poderao aceder aos recursos de rede.
A outra forma de configuracao de autenticacao baseada em MAC address
e utilizando um servidor RADIUS. Este modo de operacao e semelhante ao
do 802.1X. O authenticator envia ao servidor de autenticacao o MAC address
de origem bem como o utilizador e palavra passe configurada no switch (que
autentica o switch junto do servidor RADIUS). Se o servidor de autenticacao
receber credenciais validas do switch, envia uma mensagem de aceitacao para
o mesmo. O esquema de funcionamento descrito pode ser visto de forma
resumida na figura 2.2. A autenticacao por MAC address pode permitir
a autenticac
ao de sistemas terminais mais antigos, de terminais que nao
suportem autenticac ao 802.1x ou via web.
Uma vez que a autenticac ao baseada em MAC address autentica o dis-
positivo e n
ao o utilizador, esta sujeito a ataques do tipo MAC spoofing 1 ,
1
Ataque que consiste num cliente tentar ludibriar um servidor indicando como seu um
endereco MAC diferente do real [13].
1
2
3
4 4.1
Cliente Servidor de Servidor de
autenticao Aplicao
Figura 2.3: Autenticacao com Kerberos
n
ao sendo considerado um metodo de autenticacao seguro [70]. Permite no
entanto a existencia um certo nvel de autenticacao para dispositivos que
n
ao o poderiam fazer de outra forma.
2.3 Kerberos
Kerberos e um protocolo de autenticacao de rede, projetado para fornecer
autenticacao para aplicacoes cliente/servidor utilizando criptografia de chave
privada. O Massachusetts Institute of Technology (MIT) disponibiliza uma
implementac ao livre deste protocolo, que tambem se encontra disponvel em
muitos produtos comerciais [34].
O protocolo Kerberos foi criado como uma solucao para os problemas de
seguranca de rede permitindo a confidencialidade dos dados transmitidos e a
autenticacao mutua. Utiliza criptografia o que permite a um cliente provar
sua identidade perante um servidor e vice-versa, mesmo quando a conversao
ocorre sobre uma ligac ao de rede insegura. Alem da autenticacao m utua,
garante tambem a privacidade e a integridade dos dados trocados [45].
Em Kerberos existe um Key Distribution Center (KDC) central onde e
mantida uma base de dados de clientes e chaves privadas. O algoritmo de
encriptacao utilizado e o data encryption standard (DES) [49]. O procedi-
mento de autenticac ao esta representado na Figura 2.3. Um cliente inicia o
processo autenticando-se junto do servidor de autenticacao (KDC) (passo 1),
do qual obtem uma chave de sessao (passo 2) que lhe permite pedir acesso a
` chave de sessao e dado o nome de Ticket-granting Tickets (TGT).
servicos. A
Quando um cliente se quer autenticar perante um servico, envia um pedido
para o KDC (passo 3) que responde com um Ticket para o cliente (passo 4),
cifrado com a chave privada do cliente, e envia um segundo Ticket para o
servidor (passo 4.1), cifrado com a chave deste. O cliente decifra a resposta,
processa o seu conte udo e envia o Ticket numa mensagem de autenticacao
para o servico perante o qual se quer autenticar (passo 5). O servico, tendo
por base ambos os Tickets (o do cliente e o seu), valida a identidade do
Figura 2.4: Estrutura de mensagem do Kerberos
cliente e a restante informac

ao contida na mensagem de autenticacao [35].
Um exemplo comum da utilizac ao do protocolo Kerberos sao os domnios
Windows Active Directory.
Na figura 2.4 podemos ver a mensagem enviada pelo KDC ao cliente. A
mensagem inclui chave de sess ao Ticket-granting Service (TGS) cifrada com
a chave do utilizador, TGT para o KDC encriptada com a chave TGS. O
TGT contem chave de sess ao TGS e dados de autorizacao para o utilizador.
2.4 Captive Portal

Captive Portal e uma tecnica que forca a apresentacao de uma pagina web
aos utilizadores quando estes se tentam ligar a uma rede p ublica, requerendo
que o utilizador faca algum tipo de operacao antes de obter acesso aos re-
cursos da rede. Ate que o utilizador faca essa operacao este fica cativo. Os
Captive Portal s ao muitas vezes utilizados para apresentar uma pagina com
as condicoes de utilizac
ao da rede, publicidade, ou mesmo uma pagina de
autenticacao [29].
Um Captive Portal simples forca somente o utilizador a visualizar e acei-
tar as regras de utilizacao da rede com o clicar de um botao indicando que
concorda com as mesmas. Isto e feito com o intuito de incutir, nos utiliza-
dores, um sentimento de responsabilidade na utilizacao da rede, tentando
tambem passar-lhes a responsabilidade legal inerente às acoes cometidas por
estes.
Muitas vezes os Captive Portal sao tambem utilizados como ferramenta
de marketing e publicidade. Este proposito pode ser conseguido dando
acesso à rede apos o preenchimento de um formulario com os dados pessoais
do utilizador que posteriormente serao utilizados para contactos comerciais,
por exemplo. Tal formul ario abrir
a automaticamente no browser do utiliza-
dor quando este tentar aceder a um qualquer web site. Permite tambem que
fornecedor de servico envie publicidade para os utilizadores que se ligam à
rede.
Em implementac oes mais complexas pode requere a autenticacao do uti-
lizador atraves do username e password para que seja permitido o acesso aos
recursos de rede. Desta forma a utilizacao da rede de forma abusiva e de-
sencorajada, pois qualquer utilizacao para uso abusivo ou criminal pode ser
identificada, impedindo tambem o acesso aos recursos de rede a utilizadores
nao autorizados.
Os Captive Portal s ao principalmente utilizados em centros de negocios,
aeroportos, hoteis, que oferecem redes sem fios gratuitas. Pode tambem ser
utilizado em redes cabladas [70].
Figura 2.5: Exemplo de autenticacao por Captive Portal
2.4.1 Implementac
ao
Uma das formas de implementacao e atraves de ICMP Redirect. Nesta
implementac ao o tr
afego do utilizador e redirecionado utilizando ICMP Re-
2
direct .
Outra forma de implementacao dos Captive Portal e atraves de redire-
cionamento por DNS. Neste caso quando um cliente quer aceder a um web
site e efetuado um pedido de resolucao ao servidor de DNS. A firewall vai
garantir a que so o servidor DNS configurado no servidor DHCP pode ser
utilizado por utilizadores nao autenticados na rede. Este servidor de DNS
ir
a retornar o endereco IP do servidor onde esta alojada a pagina do Captive
Portal para todos os pedidos efetuados.
2
O ICMP Redirect e um mecanismo que funciona na camada 3 do modelo OSI e que
permite que routers fornecam informaca
o de roteamento aos clientes. Estas mensagem
indicam qual o equipamento a utilizar como default gateway.
Figura 2.6: Esquema funcional 802.1x

Porta controlada Porta no controlada Porta controlada Porta no controlada
LAN LAN
Porta Porta
no autorizada autorizada
Os Captive Portal tambem podem ser implementados num router, o de-

fault gateway da rede que protege. Este gateway bloqueia todos os pacotes
IP com destino ao exterior e captura os pedidos HTTP e HTTPS (portas
TCP 80 e 443) e redireciona-os para um servidor web (servidor de auten-
ticacao) que mostra ao utilizador a pagina de autenticacao. Se o utilizador
inserir as credenciais corretas, ou aceitar as condicoes de utilizacao, o servi-
dor de autenticacao comunica ao gateway que aquele host esta autorizado.
Assim, o gateway deixa de bloquear o trafego para fora da rede [60].
2.4.2 Limitaco
es
Algumas da implementac oes dos Captive Portal obrigam somente a que os

utilizadores se autentiquem numa pagina de login, que pode ou nao ser em
SSL, para que os seus ederecos IP e MAC passem a estar autorizados no
gateway. Este tipo de implementacao e bastante vulneravel, pois com um
simples packet sniffer e possvel conhecer o IP e o MAC de um equipamento
que esteja autenticado na rede e mascarar os seus enderecos de forma a
conseguir passar pelo gateway, fazendo-se passar pelo equipamento legtimo.
Por este motivo alguns tipos de solucao implementam outros mecanismos
adicionais para evitar este risco [70].
Os Captive Portal necessitam da utilizacao de um browser. Se um utili-
zador ao iniciar a sua sessao utilizar uma outra aplicacao que nao o browser
nao tera acesso `
a rede, nem ter
a qualquer explicacao para o fato. Por outro
lado plataformas que n ao possuam web browser tambem nao se conseguem
ligar à rede.
Figura 2.7: Componentes do 802.1x
Supplicant Servidor de Autenticao

Authenticator
2.5 802.1x
802.1X e um padr ao definido pelo Institute of Electrical and Electronics En-
gineers (IEEE) atraves do Request for Comments (RFC) 3580 [16] e consiste
num mecanismo de controlo de acesso à rede baseado em portas, utilizando
as caractersticas de acesso fsico do IEEE 802 [41]. Utiliza metodos de
autenticacao baseados na camada 2 do modelo OSI, para verificar a legiti-
midade dos utilizadores que pretendem aceder aos recursos de rede. Antes
da autenticacao so e permitida a troca de mensagens do tipo 802.1x entre
o cliente e o dispositivo de rede, estando a porta em estado nao autorizado.
Ap os a autenticacao a porta passa para o estado autorizado, sendo todo o
tr
afego permitido. Este funcionamento pode ser visualizado na Figura 2.6.
Existem tres componentes envolvidos em autenticacao 802.1X. Os tres
componentes s ao necessarios para efetuar uma troca de autenticacao [66],
est
ao representados na Figura 2.7 e sao: o supplicant, o authenticator e o
servidor de autenticac ao.
Supplicant - O supplicant, executa no cliente e e o responsavel pelo
envio das credenciais do cliente ao authenticator, em resposta ao pedido
deste. O supplicant pode tambem inicializar o dialogo de autenticacao com o
authenticator. O cliente que corre o supplicant tenta normalmente autenticar
uma interface de rede wireless, podendo no entanto ser tambem utilizado
para autenticar uma porta de um switch.
Authenticator - O authenticator e um dispositivo de rede que e res-
pons avel pela autenticacao de um supplicant que se liga a uma das suas
portas. O authenticator e tambem responsavel pelo controlo do estado das
autorizacao das suas portas. Um authenticator e tipicamente composto pe-
las portas de um switch de rede com suporte 802.1x. Em redes wireless, o
authenticator pode ser o Ponto de Acesso ou uma wireless bridge. O authen-
ticator implementa a autenticacao atraves da comunicacao com o servidor
de autenticacao.
Servidor de autentica c
ao - O servidor de autenticacao tem como
func
ao executar a autenticacao, verificando as credenciais do cliente e indi-
cando se o mesmo est a autorizado a aceder aos servicos de rede. O servidor
de autenticacao e normalmente um servidor RADIUS utilizando Extensible
Authentication Protocol (EAP).
Tipos de autentica
cao utilizados em 802.1X
O standard IEEE 802.1X implementa uma forma segura de troca de pacotes
entre o Suplicant e o Autenticator [5, 20]. O EAP e um dos mais importantes
elementos na autenticac
ao 802.1X pois fornece um mecanismo standard para
suporte de metodos de autenticac
ao adicionais como PPP. Atraves do uso do
EAP, pode ser adicionado suporte para outros protocolos de autenticacao,
incluindo smart cards, certificados de chave p ublica, one time passwords e
outros [5].
Existem varios tipos de autenticacao em EAP: EAP-MD5, Lightweight
Extensible Authentication Protocol (LEAP), EAP-Transport Layer Secu-
rity (EAP-TLS), EAP-Tunneled Transport Layer Security (EAP-TTLS) e
o Protected Extensible Authentication Protocol (PEAP), que se descrevem
de seguida:
EAP-MD5 - Utiliza um hash MD5, obtido a partir do nome de uti-

lizador e da sua password, para gerar perguntas e respostas entre o
cliente e o servidor RADIUS. Quem capturar o trafego de rede pode
descobrir a chave e obter acesso a todo o trafego capturado. E sensvel
a ataques do tipo man-in-the-middle (MITM). Nao suporta auten-
ticac
ao m
utua, so permite ao servidor validar o cliente [62].
LEAP Metodo desenvolvido pela Cisco systems. Utiliza uma versao

modificada do Microsoft Challenge Authentication Protocol (MS-CHAP).
Utiliza chaves Wired Equivalent Privacy (WEP) dinamicas e suporta
autenticac
ao m
utua. Permite que os clientes se re-autentiquem fre-
quentemente, refrescando tambem frequentemente a chave WEP, para
que se aumente a seguranca [15].
EAP-TLS Utilizado em sistemas de seguranca baseados em certi-

ficados. Proporciona autenticacao m utua atraves de certificados. A
implementacao requer o suporte de uma estrutura PKI, necessitando
de certificados tanto da parte do cliente como do servidor [61].
EAP-TTLS - E uma extensao do EAP-TLS que requer somente cer-

tificados do lado do servidor, mantendo a autenticacao m utua pois
os utilizadores s
ao autenticados na rede utilizando as sua credenciais
(nome de utilizador e password ) [23].
PEAP suporta One-Time Password (OTP), Domnios Windows ou

LDAP. E baseado na autenticacao EAP-TLS mas usa, como forma de
autenticac
ao, uma password ou um PIN em vez de certificados. Usa
chaves dinamica baseada em WEP para cifrar os dados transmitidos.
Tabela 2.1: Metodos de autenticacao EAP

Autenticacao Authenticac
ao Chaves Riscos de
do Servidor do Supplicant Din
amicas Seguranca
Ataques MITM,
EAP-MD5 Nenhum Password hash N
ao
Hijacking de sess
oes
Password Exposic
ao da identidade,
LEAP Password hash Sim
hash Ataque de dicionario
Chave P ublica
Chave P ublica
EAP-TLS (certificado ou Sim Exposic
ao da identidade
(certificado)
smart card)
Chave P ublica CHAP, PAP,
EAP-TTLS Sim Ataques MITM
(certificado) MS-CHAP, EAP
Ataques MITM,
Chave P ublica Qualquer EAP,
PEAP Sim Exposic
ao da identidade
(certificado) Chave P
ublica.
na fase 1.
PEAP tem duas fases de autenticacao. Na fase 1 e efetuada a auten-

ticac
ao do lado do servidor, com Transport Layer Security (TLS), para
criar um tunel cifrado com o cliente. Na fase 2 o cliente e autenticado
utilizando metodos como EAP Generic Token Card (EAP-GTC) ou
MS-CHAP [62].
A Tabela 2.1 compara, de forma resumida, os varios tipos de auten-

ticac
ao no que respeita a autenticacao do servidor, do supplicant, ao su-
porte para chaves din amicas e quanto às suas principais vulnerabilidades.
O EAP-MD5 apenas autentica o supplicant, nao suporta chave dinamicas e
pode ser contornado com ataques como MITM3 ou de hijacking 4 de sessoes.
O LEAP permite a autenticacao do supplicant e do servidor. Suporta cha-
ves dinamicas mas e sensvel à exposicao da identidade e a ataques de di-
cionario5 . O EAP-TLS tambem autentica tanto o servidor como o supplicant
utilizando criptografia de chave p ublica com chaves dinamicas sendo no en-
tanto sensvel `
a exposicao da identidade. O EAP-TTLS autentica o servidor
e o suplicant com suporte a chaves dinamicas e e pode ser contornado com
ataques como MITM. O PEAP autentica o servidor e o suplicant permi-
tindo chaves din amicas e e pode ser contornado com ataques do tipo MITM
e exposicao de identidade na fase 1.
3
Num ataque do tipo MITM o atacante interceta e retransmite uma comunicac ao entre
duas entidades que acreditam estar a comunicar diretamente uma com a outra.
4
O highjacking de sessoes consiste em tomar controlo de uma comunicaca
o entre duas
entidades fazendo-se passar por uma delas.
5
Ataque de dicionario e um tipo de ataque em que se tenta ganhar acesso ilegtimo a
um sistema inform atico utilizando um grande numero de palavras de um dicionario como
forma de descobrir a password.
Mensagens EAP
O protocolo EAP recorre ao Extensible Authentication Protocol (EAP) over
LAN (EAPoL) para possibilitar a comunicacao segura entre o supplicant e
o servidor de autenticacao. O EAPoL define uma formato de trama es-
pecfico que pode ser de um de 5 tipos de mensagens [20]: A EAP-Packet, a
EAPOL-Start, a EAPOL-Logoff, a EAPOL-Key e a EAPOL-Encapsulated-
ASF-Alert.
EAP-Packet: Indica que a trama contem uma trama EAP.
EAPOL-Start: Mensagem de iniciacao de autenticacao que o sup-

plicant pode utilizar para iniciar um processo de autenticacao.
EAPOL-Logoff: Mensagem de finalizacao que termina o estado de

autenticado.
EAPOL-Key: Mensagem para a troca de informacao criptografica,

como chaves e algoritmos de cifra.
EAPOL-Encapsulated-ASF-Alert: Fornece um metodo que per-

mite que as mensagens Alert Standard Forum (ASF) sejam encami-
nhadas por portas que estejam no estado nao autorizado (SNMP, por
exemplo).
As mensagens do tipo EAPOL-Start, EAPOL-Logoff e EAPOL-Key so

existem entre o supplicant e o authenticator. Ja as mensagens do tipo EAP-
Packet sao enviadas para o servidor de autenticacao depois de encapsuladas
pelo authenticator. As mensagens EAPOL-Encapsulated-ASF-Alert sao im-
portantes para manter informac ao sobre o estado da rede, sendo terminadas
pelo authenticator [8]. A Figura 2.8 demonstra troca de mensagens tpica
em 802.1X, onde um servidor RADIUS serve de servidor de autenticacao.
O cliente inicia o processo com o envio de um pedido EAPOL-Start, ao
Authenticator, que responde com um pedido EAP-Request/Identity. O cli-
ente envia a resposta ao EAP-Response/Identity do Authenticator contendo
a identidade do supplicant. Quando o supplicant recebe a mensagem EAP-
Request/Auth copia o conte udo da mensagem para o atributo User-Name
do RADIUS e reencaminha-o num pacote Access-Request para o servidor
RADIUS (Servidor de Autenticacao). Caso o servidor RADIUS nao su-
porte EAP, este responde com um Access-Reject, caso suporte, utiliza a
identidade do cliente para pesquisar na sua base de dados e cria um chal-
lenge. O challenge e u nico para o utilizador em questao e e enviado ao
Authenticator. O challenge ser a, mais tarde, comparado com a resposta do
cliente. O servidor RADIUS envia o pedido RADIUS Access-Challenge ao
cliente. O cliente valida tambem o challenge e responde com uma mensa-
gem EAP-Response/OTP. Por fim, o servidor RADIUS recebe a resposta
Figura 2.8: Autenticacao em 802.1X com RADIUS
e compara-a com a sua. Se forem identicas, significa que as credenciais do

cliente est
ao corretas e responde com uma mensagem de sucesso (RADIUS
Access-Accept) ao Authenticator que, por sua vez, envia ao cliente uma men-
sagem EAP-Success. A porta passa para o o estado autorizado. Quando o
cliente termina a sess
ao envia ao Authenticator a mensagem EAPOL-Logoff,
passando a porta para o estado nao autorizado.
2.6 An
alise comparativa
Os metodos de controlo de acesso à rede apresentados anteriormente tem
uma abordagem diferenciada. A autenticacao baseada em endereco MAC
e em 802.1X limitam a ligacao do equipamento à rede, nao sendo possvel
qualquer troca de mensagens com os equipamentos de rede ate que o equipa-
mento seja identificado ou autenticado. O Kerberos foca-se na autenticacao
com domnio Active Directory. O Captive Portal consiste numa autenticacao
por via de uma p agina web de autenticacao, que requer a utilizacao de um
browser, mas tambem, a intervencao de um firewall e/ou router.
A autenticac
ao baseada em enderecos MAC tem como grande desvanta-
gem o fato de ser necessaria a identificacao dos enderecos MAC autorizados
e a sua configurac
ao em todos os equipamentos de rede. Tal torna-se extre-
mamente moroso em redes complexas em que existam muitos equipamentos
Tabela 2.2: Tecnologias de controlo de acesso a rede

802.1X Captive Portal Endereco MAC Kerberos
Requer browser Nao Sim Nao Nao
Registo Utilizador Utilizador Equipamento Utilizador
VLANs din amicas Sim Nao Sim Nao
AAA Sim Nao Nao Nao
Sensvel a MAC spoofing Nao Sim Sim Nao
de rede e muitos utilizadores. Este problema pode ser mitigado utilizando

um servidor RADIUS, onde se pode centralizar os enderecos fsicos dos equi-
pamentos que podem aceder aos recursos de rede. No entanto, em ambientes
com muitos utilizadores, implica efetuar o registo de todos os equipamentos
autorizados. Sempre que um utilizador quiser ligar um novo equipamento à
rede, tal requer que o mesmo seja registado e autorizado no sistema. Este
metodo apresenta um nvel limitado de seguranca uma vez que e relati-
vamente f acil de contornar com a clonagem de um endereco MAC de um
equipamento autorizado (MAC spoofing). A sua utilizacao podera ser inte-
ressante em equipamentos que n ao suportem outros tipos de autenticacao.
A autenticac
ao por Captive Portal implica, desde logo, a utilizacao de
um browser. Em alguns casos pode ser um problema. Este metodo de con-
trolo de acesso `
a rede pode tambem ter problemas quando deparado com o
spoofing de enderecos (IP ou MAC). Deste modo um utilizador nao autori-
zado pode mascarar o seu endereco, recorrendo a um endereco autorizado e,
desta forma, aceder aos recursos da rede sem que tenha de ser identificado.
O 802.1X opera ao nvel das portas de um switch. A porta so passa para
o estado autorizado ap os ser efetuada autenticacao com sucesso junto de um
servidor de autenticac ao. Nao e possvel aceder à rede sem proceder a au-
tenticac
ao pois a porta esta no estado nao autorizado. Apos a autenticacao,
o utilizador pode ser colocado numa VLAN predeterminada, dependendo
dos privilegios do mesmo. A autenticacao e feita no incio da sessao. A
autenticacao e feita de modo centralizado, recorrendo por exemplo a um
servidor de autenticac ao RADIUS. Como o controlo da ligacao e efetuado
ao nvel da porta do swicth, ataques do tipo MAC e IP spoofing nao sao
possveis, sendo o equipamento obrigado a proceder à autenticacao previa
para que lhe seja concedido acesso à rede.
A Tabela 2.2 resume as caratersticas principais de cada uma das tec-
nologias de controlo de acesso `
a rede descritas anteriormente. A ttulo de
exemplo, pode-se verificar que a autenticacao por 802.1X nao necessita da
execucao de um browser, o que e validado e a autenticacao do utilizador e
nao do equipamento, suporta a atribuicao dinamica de VLANs de acordo
com o utilizador que se autentica, suporta AAA, e nao e sensvel a ataques
do tipo MAC spoofing.
2.7 Conclus
ao
Existem v arias soluc
oes que permitem efetuar o controlo de acesso à rede.
Dependendo do cen ario de implementacao, todas elas poderao ser considera-
das como opc oes v
alidas, pese embora todas com vantagens e desvantagens.
A tecnologia 802.1X e aquela que se apresenta como mais adequada para
ser implementada em redes de media ou grande complexidade pelo fato de
ser uma soluc ao robusta, facilmente escalavel, apropriada para ambientes
heterogeneos, com grande diversidade de sistemas operativos envolvidos e
de diferentes tipos de equipamentos cliente. Esta solucao, quando imple-
mentada de forma interligada com o servidor RADIUS, permite efetuar a
autenticac
ao num Active Directory local, e assim manter um ponto u nico de
autenticac
ao.
Captulo 3
Protocolo Internet
O IP, ou protocolo Internet, possibilita a comunicacao entre equipamen-

tos e aplicac
oes heterogeneas, podendo estes inclusive ser desenvolvidas por
diferentes fabricantes. Existem duas versoes do IP e, atualmente, ambas
coexistem ` a escala global. As versoes sao a versao 4 (IPv4) e a versao 6
(IPv6). O IPV4 apresenta algumas limitacoes, o que levou ao surgimento
do IPv6.
3.1 IP vers
ao 4 (IPv4)
O protocolo IPv4 foi criado nos anos 70 e definido pelo RFC 791 [3] em
1981. E um dos principais protocolos de rede baseados em standards na
Internet, tendo sido a primeira versao implementada na Advanced Research
Projects Agency Network (ARPANET) em 1983. Nos dias de hoje ainda e
responsavel pela maioria do tr
afego [1] na Internet. O protocolo IP e um dos
mais importantes no TCP/IP. No modelo de referencia OSI, o IP trabalha
na camada de rede e a sua principal funcao e e a identificacao dos hosts
baseando-se no seu endereco l ogico, de forma a poder encaminhar dados
entre esse host e outros na rede. O endereco logico de um host e o seu
endereco IP. O esquema de enderecamento do IPv4 e utilizado ate aos dias
de hoje e permite a identificac
ao de hosts na rede. Este sistema e baseado
num endereco logico de 32 bits. [9]
IPv4 e um protocolo n ao orientado à conexao que opera num modelo
de menor esforco para a entrega de pacotes, nao garantindo a entrega, a
correta sequencia, nem evita duplicacao de pacotes. Estes aspetos, incluindo
integridade de dados, s ao dirigidos para protocolos de camada superior,
como o TCP, por exemplo.
19
20 Protocolo Internet
Tabela 3.1: Classes de enderecamento IPv4

Primeiro Numero Enderecos Primeiro
Classe Mascara
octeto de redes por rede endereco
A 1-127 255.0.0.0 126 16777214 0.0.0.0
B 128-191 255.255.0.0 16382 65534 128.0.0.0
C 192-223 255.255.255.0 2097150 254 192.0.0.0
D (multicast) 224-239 224.0.0.0
E (reservada) 240-255 240.0.0.0
3.1.1 Enderecamento
Antes da implementac ao do IPv4, os engenheiros da ARPANET discutiram
se o tamanho de um endereco IP deveria ser de 32 ou de 128 bits, tendo
sido decidido que seria de 32 bits. Isto representa um total de 4.294.967.296
(232 ) enderecos. Na altura, a necessidade de um n umero maior de hosts do
que este n ao era previsvel [18].
Para permitir redes de diferentes dimensoes foram criadas as classes de
rede. O enderecamento IPv4 esta dividido em cinco classes, A, B, C, D,
E. As classes A, B, e C tem um tamanho de bits diferentes para enderecar
um host de rede. Os enderecos da classe D estao reservados para multicast,
enquanto que a classe E estaria reservada para uso futuro. Um exemplo de
um endereco de IPv4 e 172.20.100.1. Este e composto por 4 octetos de 8
bits, i.e. um endereco de 32 bits. O endereco anterior tera a seguinte repre-
sentacao em binario 10101100 00010100 01100100 00000001. Na Tabela 3.1
podemos ver como os enderecos das classes de IPv4 sao atribudas, incluindo
o numero de hosts que cada classe tem.
Esta divisao de enderecamento em classes foi abandonado em 1993 com a
publicacao do RFC 1517 e substitudo pelo Classless Inter-Domain Routing
(CIDR) [22]. Enquanto o enderecamento por classes implica um tamanho
de rede fixo para cada classe, em CIDR uma rede pode ter tamanho variavel
que depende do n umero de bits da mascara de rede (por exemplo /24). O
CIDR permite assim o reparticionamento do espaco de enderecamento de
forma a que blocos de enderecos de diferentes tamanhos possam ser alocados
aos utilizadores de acordo com as suas necessidades.
O sistema de enderecamento IP inclui uma mascara de rede que nos
permite distinguir entre enderecos de rede e enderecos de host. Por exem-
plo assumindo-se um endereco IP 192.168.0.2 com a mascara de rede de
255.255.255.0, o endereco 192.168.0 identifica a rede (classe C) e o endereco
0.0.0.2 identifica o host. Um endereco IP nao identifica maquinas, mas in-
terfaces de rede de m aquinas. Um equipamento que possua dois interfaces
de rede, pode ter dois enderecos IP. Alem destes, possui tambem outros
enderecos especiais como o endereco de loopback e outros dependendo das
suas funcoes [47].
Tabela 3.2: Enderecamento privado

Bloco de Numero Numero
Mascara
enderecos de redes de hosts
10.0.0.0 -
255.0.0.0 126 16777216
10.255.255.255
172.16.0.0 -
255.255.0.0 16382 1048576
172.31.255.255
192.168.0.0 -
255.255.255.0 2097150 65536
192.168.255.255
Endere
camento Privado
A utilizac
ao massiva e global do IPv4 levou ao esgotamento gradual do
espaco de enderecamento. De forma a poupar enderecos e possibilitar uma
melhor gest ao de enderecos disponveis, surgiram algumas tecnicas para mi-
nimizar o problema. Tecnicas como o Network Address Translation (NAT),
que permite a utilizac ao de enderecamento privado nas redes locais [9], e
um exemplo. Do leque de enderecos do IPv4 disponveis, tres blocos de
enderecos estao reservadas para uso em redes privadas[56]. Estas gamas de
enderecos IP n ao s
ao rote
aveis fora de redes privadas. Equipamentos com
endereco privado n ao podem comunicar diretamente com equipamentos em
redes publicas, sendo necessaria a utilizacao de NAT para que o consigam
fazer. A Tabela 3.2 resume os blocos de enderecamento privado em IPv4.
A utilizac
ao de enderecamento privado levanta alguns problemas. Uma
vez que os enderecos privados s ao ignorados pelos routers p ublicos, duas
redes privadas (em localizac oes distintas) nao conseguem comunicar dire-
tamente entre elas. Para que o consigam fazer e necessaria a utilizacao
de VPNs. Assim sendo, quando uma rede quiser comunicar com outra rede
remota, recorre-se a um encapsulamento de pacotes para que os mesmos pos-
sam circular na Internet, sendo estes desencapsulados na rede de destino.
Pode tambem existir a cifra de pacotes por forma a garantir confidenciali-
dade na comunicac ao.
3.1.2 Limitaco
es do IPv4
O IPv4 n ao sofreu mudancas significativas desde que o RFC 791[54] foi
publicado em 1981. Sendo um protocolo robusto, de facil implementacao,
interoperavel, foi respons
avel pela crescimento da Internet ate ao tamanho
que tem nos hoje em dia. No entanto o desenho inicial do IPv4 nao antecipou
varios problemas.
A limitac
ao mais significativa do protocolo IPv4 reside na exaustao do
enderecamento p ublico existente. O protocolo IPv4 so tem cerca de 4 mil
milhoes de enderecos disponveis[9]. O desenvolvimento de aplicacoes moveis
e de servicos domesticos provocou um enorme aumento de dispositivos li-

gados ` a Internet. Existem cada vez mais utilizadores a utilizar ligacoes
permanentes ` a Internet baseadas em Digital subscriber line (DSL), acessos
3G ou fibra. Por outro lado, o enderecamento dinamico nao e uma solucao
v
alida para utilizadores que necessitam de conetividade à Internet nos dois
sentidos [58].
Para reduzir o n umero de enderecos necessarios por uma organizacao e
de forma a poupar enderecos p ublicos, desenvolveu-se a estrategia de en-
derecamento privado com NAT. O NAT permite que, por exemplo, um rou-
ter sirva de ponte entre a Internet e uma rede privada [9], possibilitando a
partilha do endereco p ublico deste pelos demais equipamentos na rede local.
Desta forma um u nico endereco p ublico pode representar um grupo de dis-
positivos ou computadores. A rede local utiliza uma gama de enderecamento
privado IPv4 para comunicar entre dispositivos da rede local. Isto permite
que as comunicac oes internas sejam estabelecidas facilmente com os dispo-
sitivos locais, no entanto para qualquer comunicacao com a Internet tera
que existir NAT, pois as redes locais nao podem ser enderecadas em redes
publicas. Existem algumas desvantagens na utilizacao de NAT. Em pri-
meiro lugar as comunicacoes ponto a ponto sao mais difceis de configurar
pois n ao existe conetividade ponto a ponto, pode provocar problemas com
algumas aplicac oes (como File Transfer Protocol (FTP) e Session Initiation
Protocol (SIP)) uma vez que interfere com os campos do cabecalho[58].
A maioria das implementacoes IPv4 obriga a que a configuracao seja efe-
tuada manualmente ou entao que seja utilizado um servico de configuracao
autom atico como o DHCP. Em redes com um elevado n umero de dispositi-
vos, a existencia de um mecanismo de configuracao mais simples, que nao
dependa de servicos DHCP, podera ser preferencial.
Comunicac oes privadas sobre um meio de comunicacao p ublico como a
Internet requer a utilizacao de servicos de criptografia que protejam os dados,
garantindo a sua confidencialidade, integridade e autenticidade [67]. O IPv4
nao tem suporte nativo para seguranca. Embora exista um standard para
a seguranca que e utiliz avel em IPv4, o Internet Protocol Security (IPSec),
este e opcional. Algumas implementacoes de protocolos de seguranca sao
propriet arias, sendo necessario o pagamento de licencas para a utilizacao
das mesmas [58] (ex: Check Point IPSec VPN, Cisco AnyConnect Secure
Mobility Client).
Em IPv4 e difcil identificar o tipo do trafego enquanto este e transmitido.
Essa identificacao depende do campo de 8 bits Type of Service (TOS), e da
identificac
ao do payload [9]. O campo TOS tem uma funcionalidade limitada
e foi redefinido ao logo do tempo, tendo neste momento varias interpretacoes.
Por esse motivo e difcil priotizar trafego como vdeo streaming, entre outros,
em IPv4 [58].
A necessidade de enderecos IPv4 e de acessos à Internet continua com
um elevado crescimento, implicando que as tabelas de roteamento acompa-
nhem este ritmo elevado. Tal deve-se, em parte, à forma como os enderecos
IPv4 sao atribudos, muitas vezes em blocos fragmentados. A necessidade
de gravar rotas para um grande n umero de enderecos num espaco de en-
derecamento limitado constitui um desafio na construcao das tabelas de
roteamento, alem de afetar o desempenho dos equipamentos.
Devido ` a funcionalidade de broadcast que os dispositivos IPv4 possuem,
a rede pode-se tornar congestionada e sobrecarregada ja que este tipo de
pacotes s
ao enviados para todos os enderecos na rede local.
Em IPv4, o campo Time to live (TTL)1 , que tem o valor recomendado
de 64 [55], faz parte do cabecalho dos pacotes IP. Se os dados nao chegarem
ao seu destino dentro desse valor estes expiram, sendo solicitado um novo
envio, provocando m ultiplos pedidos pelo mesmo datagrama e atrasando a
transmissao. Este comportamento pode causar problemas, principalmente
em transmiss ao de dados em tempo real como Voice over Internet Protocol
(VOIP) ou streming de vdeo[58] [9].
3.2 IP vers
ao 6 (IPv6)
IPv6, tambem conhecido por IP next generation (IPng), e a versao do pro-
tocolo IP que foi desenvolvida para suceder ao IPv4 [7]. Foi desenvolvido
pelo Internet Engineering Task Force (IETF) entre 1991 e 1997 e formal-
mente descrito no RFC 2460 [17]. A sua utilizacao oficial iniciou-se em 2004
quando o Internet Corporation for Assigned Names and Numbers (ICANN)
adicionou aos seus servidores Domain Name Service (DNS) enderecos IPv6
[9]. O IPv6 n ao foi desenvolvido com o objetivo de ser radicalmente diferente
do IPv4, mas antes como uma evolucao deste. A generalidade das funciona-
lidades do IPv4 foram mantidas, no entanto, algumas funcionalidades nao
eram muito utilizadas, pelo que os campos respetivos do cabecalho IP foram
removidos [7]. Os campos removidos foram Internet Header Length (IHL),
Identification, Flags, Fragment Offset, Header Checksum, Options e Pad-
ding.
O IPv4 n ao consegue fornecer os enderecos IP necessarios para suprimir
as necessidade do nosso mundo [9]. Tal como o IPv4, o IPv6 e um protocolo
que opera na camada de rede, baseado em comutacao de pacotes e que
fornece transmiss ao de datagramas ponto a ponto entre redes IP [7]. Redes
IPv6 tambem operam em melhor esforco.
O espaco de enderecamento em IPv6 e muito maior que o espaco utilizado
em IPv4. Passou de 32 para 128 bits, i.e passou de 232 = 4.294.967.296
enderecos possveis, para
2128 = 340.282.366.920.938.463.374.607.432.768.211.456
1
TTL e um mecanismo que limita o n
umero de retransmiss
oes de um pacote numa rede
IP. Explicita o n
umero m
aximo de saltos do pacote, sendo decrementado em 1 por cada
router que passa.
enderecos possveis. Tal capacidade de enderecamento representa cerca de

4x1028 enderecos por cada pessoa em todo o mundo [31].
Este aumento de enderecos disponveis permite que cada vez mais dispo-
sitivos se liguem à Internet, flexibilizando a alocacao dos enderecos. Au-
menta tambem a eficiencia dos protocolos de routing devido ao seu en-
derecamento hierarquico e à adocao de um cabecalho IP mais simples. A
tecnica de NAT, largamente utilizada como forma de aliviar a exaustao de
enderecos IPv4, foi eliminada em IPv6 [7].
Existe ainda alguma discussao sobre a eliminacao do NAT em IPv6. Essa
discuss
ao e clara com a publicacao do RFC 5902 pelo Internet Architecture
Board (IAB). Por um lado existe quem defenda que nao ha necessidade de
NAT em IPv6, e que por isso nao e necessario que seja definido nenhum
standard para NAT em IPv6. Por outro, quem defende a necessidade de
NAT em IPv6 defende que este deve ser standard de forma a evitar os
problemas existentes nas implementacoes de NAT em IPv4. Os defensores
da existencia de NAT em IPv6 defendem que este pode ser a solucao para
v
arios problemas como: a necessidade de alteracao de enderecamento caso
se mude de ISP (uma vez que enderecos IP sao fornecidos por estes), Site
Multihoming que obriga que os equipamentos tenham dois enderecos IP
distintos, ofuscac
ao da rede, entre outros [63].
O IPv6 foi desenvolvido como um substituto do IPv4, pelo que estes
n
ao sao interoperacionais, fato que complica a transicao de IPv4 para IPv6.
Foram, no entanto, desenvolvidos varios mecanismos para permitir a comu-
nicac
ao entre dispositivos IPv4 e IPv6 [6].
3.2.1 Enderecamento
Os enderecos IPv6 tem 128 bits e identificam equipamentos. Em IPv6 exis-

tem tres tipos de enderecos que sao definidos no RFC 4291[28]: enderecos
unicast, anycast e multicast. Nao existem enderecos de broacast, dado que
as suas func
oes s
ao parcialmente desempenhadas pelos enderecos multicast
e anycast.
Um endereco unicast identifica um u
nico equipamento. Um pacote envi-
ado para um endereco unicast e entregue no interface identificado por esse
endereco. Um endereco anycast identifica um conjunto de equipamentos.
Este esquema de enderecamento e novo. Um pacote enviado para um en-
dereco anycast e entregue ao primeiro equipamento identificado por esse
endereco, ou ao mais proximo de acordo com a informacao de routing. Um
endereco multicast identifica um conjunto de equipamentos. Um pacote en-
viado para um endereco multicast e entregue a todos os equipamentos que
fazem parte do grupo multicast.
Figura 3.1: Comparac

ao entre cabecalhos IPv4 e IPv6
Cabealho IPv4 Cabealho IPv6
Type of
Version IHL Total Length Version Traffic Class Flow Label
Service
Fragment Next
Identification Flags Payload Length Hop Limit
Offset Header
Time to Live Protocol Header Checksum
Source Address
Source Address
Destination Address
Options Padding
Destination Address
Nome do campo mantido de IPv4 para IPv6

Campo eliminado em IPV6
Posio e nome alterado em IPv6
Novo campo em IPv6
3.2.2 Novas funcionalidades

O desenvolvimento do IPv6, alem de ter como objetivo a resolucao do pro-
blema da exaust ao de enderecos, adicionou novas funcionalidades e melho-
ramentos quando comparado com o IPv4[52] [26]. O IPv6 utiliza enderecos
com 128 bits, o que aumenta drasticamente o n umero de enderecos dis-
ponveis.
Em IPv6 a forma como os blocos de enderecos sao atribudos foi alterada
de forma a evitar a desagregac ao de blocos de enderecos. Os enderecos IP
sao divididos em blocos e a sua gestao e delegada, normalmente baseando-
se em criterios regionais. IPv6 tambem permite que os ISPs agreguem os
prefixos das redes dos clientes num unico prefixo que e anunciado à Internet.
O cabecalho do pacote IPv6 e mais simples, tal facilita o processamento
dos pacotes. O cabecalho em IPv6 tem seis campos e dois enderecos, en-
quanto o cabecalho IPv4 tem dez campos fixos, dois enderecos e um campo
de opcoes com tamanho vari avel. Um dos campos eliminados e o checksum,
pelo que deixa de ser necess ario ser recalculado em todos os saltos. Na Fi-
gura 3.1 podemos ver os dois cabecalhos IP com a indicacao de quais os
campos alterados no IPv6.
A eliminac
ao do NAT permite a ligacao end-to-end na camada IP. Redes
ponto a ponto tornam-se mais f aceis de criar e gerir, servicos como o VOIP
tornam-se mais robustos. O protocolo IPSec, que providencia confidenciali-
dade, autenticacao e integridade de dados esta integrado no IPv6, introdu-
zindo dois cabecalhos de extensao opcionais: Authentication Header (AH) e
Encrypted Security Payload (ESP).
A auto-configurac ao em IPv6 e uma funcionalidade base que permite
que a configuracao de um interface de rede, quando este se liga à rede de
forma autom atica seja feita de forma automatica. Um router, periodica-
mente, envia o prefixo da rede local numa mensagem chamada de router
advertisement. Um host pode gerar o seu proprio endereco IP, por exem-
plo, juntando o seu endereco MAC, convertido no formato Extended Unique
Identifier (EUI) 64-bit, aos 64 bits do prefixo da rede local que e anunciado
pelos routers. Esta funcionalidade a que se chama de stateless autoconfi-
guration vai permitir estabelecer a ligacao à rede de com maior rapidez,
especialmente em redes de grandes dimensoes.
Em IPv4, o multicast era uma expansao à especificacao base. Em IPv6,
o multicast faz parte da especificacao base do protocolo, pelo que todos
os equipamentos IPv6 tem suporte multicast. Estas alteracoes tornam a
utilizac
ao de multicast em IPv6 mais simples e facil de configurar, bem
como aumenta as suas funcionalidades.
O suporte para mobilidade foi uma das funcionalidades que foram in-
cludas no IPv6. O seu objetivo e permitir que um dispositivo se desloque
de uma rede para outra, mantendo ligacoes TCP ativas, mesmo mudando o
seu endereco IPv6. O protocolo Neighbor Discovery Protocol (ND) e a auto-
configuracao de endereco garantem conetividade para o dispositivo de forma
transparente, independentemente de onde o dispositivo esteja ligado e sem
a necessidade de nenhum dispositivo adicional. Para conseguir isto IPv6
introduz quatro novos conceitos que vao permitir o suporte à mobilidade
[32]
Home Address - E um endereco unicast global para um no movel, sendo
utilizado como o endereco permanente para esse no. Este endereco
est
a dentro da gama de enderecos do seu home link. Os mecanismos
de routing normais entregam os pacotes destinados ao no movel no seu
home link .
um endereco unicast para um no movel enquanto
Care-of Address - E
este est
a numa rede estranha. O prefixo de rede do endereco e o prefixo
da rede onde este se encontra. Um no movel pode ter varios care-of
Addresses. O que estiver registado no seu home agent e o primario.
Binding - E a associacao do home address de um no movel com o seu
care-of address juntamente com o tempo restante para essa associacao.
Home Agent - Um router no home link de um no movel em que o no
regista o seu care-of address atual. Quando o no movel nao esta na
rede local, o home agent interceta os pacotes destinados ao endereco
local do no, encapsula-os e envia-os para o care-of address do no que
est
a registado.
3.2.3 Transic
ao e Interoperabilidade IPv4/IPv6
A atribuic
ao dos u
ltimos enderecos IPv4 pela ICANN [36] vem realcar a
urgencia da implementacao do IPv6. No entanto, a adocao do IPv6 tem
sido pouco expressiva, apesar dos seus benefcios. Isto deve-se à existencia
de varias restric
oes na transic
ao para IPv6 que dificultam uma transicao
simples.
O IPv6 foi pensado para ser uma alternativa ao IPv4 e nao uma extensao
deste, n ao tendo sido delineado um plano de transicao coerente. Tal tornou a
transicao mais complexa. Equipamentos com enderecos IPv4 nao conseguem
comunicar com equipamentos com enderecos IPv6. Sistemas antigos podem
nunca ser capazes de funcionar em IPv6 [25].
Durante um eventual perodo de transicao numa organizacao, os nos
IPv6 necessitam de comunicar com nos IPv4, e eventuais redes IPv6 que
estejam isoladas v ao necessitar de utilizar a rede IPv4 para comunicar en-
tre elas. Existem v arias tecnologias de suporte a esta transicao IPv4/IPv6
[25]. Equipamentos poder ao ser configurados em dual stack, passando a
ter suporte completo para as duas versoes do IP[24][51]. Poder-se-a utili-
zar tunneling, estabelecendo-se t uneis ponto-a-ponto onde os pacotes IPv6
sao encapsulados em pacotes IPv4 e transportados por infraestruturas IPv4
[24][51]. Finalmente, pode-se recorrer a tecnologias de conversao (transla-
tion) que convertem uma vers ao do protocolo na outra, permitindo assim a
interoperabilidade[18].
Dual Stack
Dual stack e um mecanismo que fornece suporte total para as duas versoes
do protocolo aos routers e hosts de uma rede. Trata-se do mecanismo mais
simples, permitindo que aplicac oes IPv4 e IPv6 coexistam num ambiente de
dupla pilha IP [6].
Um host dual stack e tambem por vezes referido como host IPv6/IPv4.
Em comunicac oes com outro host IPv4 comporta-se como um host IPv4,
em comunicac oes com um host IPv6 comporta-se como um host IPv6. De-
pendendo de como est a implementado, pode ter tres modos de operacao.
IPv4-only, IPv6-only ou IPv4/IPv6 [31].
Um n o em dual stack tem pelo menos um endereco para cada protocolo,
utilizando DHCP ou configurac ao estatica para IPv4 ou DHCPv6, Stateless
address autoconfiguration (SLAAC), ou configuracao estatica em IPv6. O
servico DNS e utilizado independentemente do protocolo para efetuar a re-
solucao de nomes e enderecos IP devendo o mesmo ser capaz de resolver os
dois tipos registos DNS. Um registo do tipo A representa enderecos IPv4,
um registo do tipo AAAA IPv6. Dependendo de como o servico DNS e
contactado (IPv4, IPv6 ou ambos) este pode retornar um endereco IPv4,
um endereco IPv6 ou ambos. Mecanismos de selecao de endereco terao que
garantir que as ligacoes ser
ao estabelecidas em qualquer um dos casos ante-
riores. Os mecanismos de DNS, tanto do cliente como da aplicacao, possuem
opcoes de configurac
ao que definem qual a ordem dos enderecos a utilizar,
neste caso, qual vers ao do protocolo a utilizar. Um servidor DNS pode ope-
rar tanto numa rede IPv4 como IPv6 para resolver enderecos de ambas as
vers oes.
Uma rede dual stack e uma infraestrutura em que os dois protocolos
s
ao roteados e encaminhados nos routers. Numa estrutura com dual stack
configurado pode-se iniciar a migracao de aplicacoes para IPv6, mudando o
tr
afego de IPv4 para IPv6 ao logo do tempo. Nenhuma tecnica de tunneling
ou de translation e utilizada, aumentando o desempenho, escalabilidade e
eficiencia. Outra vantagem e que ambas as versoes correm em modo na-
tivo. Todo o equipamento de rede tem de executar ambas as versoes do IP,
o que significa que todas tabelas (routing, ligacoes, etc) sao mantidas em
duplicado. Todas as configuracoes sao efetuadas tambem em duplicado [26].
Tunneling IPv6/IPv4
Em tunneling, o tr afego IPv6 e encapsulado em pacotes IPv4 para que estes
possam ser enviados atraves de uma rede IPv4, formando assim um t unel
IPv6. Este mecanismo permite que redes IPv6 isoladas comuniquem sem a
necessidade de efetuar migrar a estrutura IPv4 que as interliga [58, 31].
Um t unel IPv6 pode ser configurado manualmente. A utilizacao princi-
pal de um t unel deste tipo e a de fornecer ligacoes permanentes entre dois
routers de permetro, entre um sistema terminal e um router, ou entre redes
IPv6 remotas. Os equipamentos utilizados como endpoints tem que estar
configurados em dual stack. Como cada t unel e gerido de forma indepen-
dente, quantos mais n os existirem, mais tuneis serao necessarios. Tal podera
implicar um grande esforco de gestao. NAT nao e permitido neste tipo de
t
unel [31].
T
uneis IPv6 sobre IPv4 com Generic Routing Encapsulation (GRE) uti-
lizam o protocolo GRE para implementar tecnicas de encapsulacao ponto a
ponto. Podem ser implementados t uneis manuais entre dois pontos, com um
t
unel separado para cada sentido da informacao. Os equipamentos utilizados
como endpoints tem que estar configurados em dual stack [25].
T
uneis baseados em Intrasite Automatic Tunnel Addressing Protocol
(ISATAP) s ao configurados automaticamente e principalmente utilizados
entre hosts e routers. Com ISATAP, um t unel e criado entre um host e
um router. O t unel e estabelecido utilizando os enderecos IPv4 dos dois. O
estabelecimento do t unel e automatico, sendo estabelecido pelo host quando
necessario[25].
T
uneis autom aticos com enderecamento compatvel com IPv4 tambem
s
ao possveis. Estes t uneis utilizam enderecos IPv6 compatveis2 com IPv4.
O destino do t unel e determinado automaticamente pelo endereco IPv4. O
host ou router em cada ponta do t unel tem que suportar as duas versoes do
protocolo IP. Estes t uneis podem ser configurados entre border routers ou
entre um host e um border router. A utilizacao desta tecnica e uma forma
2
Estes enderecos, atualmente em desuso, sao enderecos IPv6 em que os 96 bits mais
significativos est
ao a zero e coloca-se um endereco IPv4 nos 32 bits menos significativos.
simples de criar tuneis IPv6 sobre IPv4, mas nao e escalavel para redes de
grandes dimens oes [33].
Tuneis autom aticos 6to4 est
ao especificados no RFC 3056 [14]. Este tipo
de t
unel permite que redes IPv6 isoladas se liguem atraves de redes IPv4
e permite a ligacao a redes IPv6 remotas. Um cenario de implementacao
simples e a interligac
ao de v
arios sites IPv6, em que cada um deles possui
uma ligacao
a Internet em IPv4 [31].
Translation
O conceito de traduc ao de enderecos [46] nao e novo devido à utilizacao ge-
neralizada de NAT nas redes IPv4. O conceito que reside por tras do NAT e
da tecnica de translation e semelhante. Translation permite a comunicacao
entre hosts IPv4 com hosts IPv6 sem recurso a dual stack. Este tipo de
comunicac ao n
ao e possvel quando se recorre à utilizacao de tuneis [68].
Num perodo de transic ao em que existem varios servicos, tanto em redes
locais como na Internet, que ainda nao suportam IPv6, nao seria possvel, a
equipamentos numa rede IPv6 sem dual stack, comunicar com tais servicos.
Este facto justifica a import ancia desta tecnologia [31]. O recurso a meca-
nismos de traduc ao de enderecos acarretam alguma complexidade. Quando
um host IPv6 tenta comunicar com um host IPv4, devera resolver o nome
desse equipamento num endereco do tipo AAAA (IPv6), e nao num endereco
do tipo A (IPv4). Tal implica a utilizacao do DNS64 [68].
O Stateless IP/ICMP Translator (SIIT), definido pelo RFC 2765 [50],
e um mecanismo que procede ` a conversao dos cabecalhos dos pacotes en-
tre os formatos IPv4 e IPv6. Esta tecnica define uma nova classe de en-
derecos IPv6, de nome IPv4-translated addresses, identificada com o prefixo
::ffff:0:0:0/96 podendo ser escrita como ::ffff:0:a.b.c.d em que o endereco IPv4
a.b.c.d se refere a um n o IPv6. Este algoritmo pode ser usado para permitir
que um host IPv6 que n ao tenha um endereco IPv4 comunique com um host
IPv4-only. Esta tecnica tem as mesmas limitacoes do NAT.
O NAT 64, definido pelo RFC 6146 [10], e um mecanismo que permite
a comunicac ao entre um host IPv6 e um servidor IPv4. Consiste num ser-
vidor com pelo menos um endereco IPv4 e um segmento de rede IPv6 de 32
bits (que poder a ser por exemplo 2001:690:23c0:2000::/96). O cliente IPv6
junta o endereco IPv4 (ex. 193.136.58.99) com que quer comunicar com o
segmento de rede IPv6 e envia os pacotes para o endereco resultante (ex.
2001:690:23c0:2000:193.136.58.99). Uma instalacao NAT64 simples consiste
num gateway com dois interfaces, um ligado a uma rede IPv4 e outro a
uma rede IPv6. Tr afego da rede IPv6 e encaminhado para o gateway que
faz todas as convers oes necess arias para transferir os pacotes entre as duas
redes. A convers ao nao e simetrica pois o enderecamento em IPv6 e muito
maior que em IPv4, por isso o mapeamento um para um nao e possvel. O
gateway mantem o mapeamento IPv6-to-IPv4 que pode ser estabelecido ma-
nualmente (stateless mapping) ou automaticamente (statefull mapping).O

NAT64 requer a utilizacao de DNS64.
O Network Address Translation/Protocol Translation (NAT-PT) foi de-
finido pelo RFC 2766 [65] mas, devido a varios problemas de estabilidade e
de seguranca, foi declarado obsoleto [46].
O Transport Relay Translator (TRT), definido pelo RFC 3142 [27], e
um protocolo de conversao que opera na camada de transporte e que e
baseado num proxy DNS. Recebe pedidos de hosts IPv6 e, se o nome estiver
associado a um endereco IPv4, retorna um endereco IPv6 composto por
um prefixo IPv6 de 64 bits, seguidos de 32 bits de zeros mais o endereco
IPv4. Quando um host tenta comunicar com outro atraves do TRT, duas
ligac
oes s
ao estabelecidas: uma entre a origem e o servico TRT e outra entre
o dispositivo TRT e o destino, cada uma delas no seu protocolo nativo.
Depois disto, o TRT transmite os pacotes entre a origem e o destino de
forma transparente, traduzindo cada um deles conforme necessario [40]. Este
metodo foi substitudo pelo DNS64.
O DNS64, definido pelo RFC 6147 [11], e uma funcionalidade do servico
de DNS. Um servidor DNS64 ao receber um pedido de resolucao de um
registo do tipo AAAA para o qual so dispoem de registos do tipo A, cria
automaticamente um registo do tipo AAAA a partir do registo A. A pri-
meira parte do endereco resultante aponta para o tradutor IPv4/IPv6, a se-
gunda parte inclui o endereco IPv4 do registo tipo A. O tradutor IPv4/IPv6
e normalmente um servidor NAT64. No caso de ser definido o prefixo
2001:690:23c0:2000::/96 para o DNS64, um pedido de DNS do tipo A que
retorne o endereco 193.136.58.99 sera convertido para o endereco 2001:690:-
23c0:2000:193.136.58.99.
3.3 Conclus
ao
A vers ao 6 do IP foi desenvolvido para superar muita das limitacoes do IPv4,
introduzindo tambem funcionalidades novas que visam tornar a operacao
da rede, bem como o trabalho dos administradores de redes, melhor e mais
fi
avel. O IPv6 tem diferencas significativas relativamente ao IPv4. Uma
vez que o protocolo IPv6 nao e compatvel com IPv4, e necessaria a imple-
mentac ao de mecanismos de transicao para a implementacao do IPv6. Exis-
tem v arios mecanismos desenvolvidos especificamente para suportar esta
transic
ao e que permitem a coexistencia das duas versoes do IP.
Captulo 4
Rede ESTG/IPv6
A possibilidade de acesso por parte dos utilizadores a varias redes publicas

provoca problemas relacionados com a seguranca informatica, tais como
a possibilidade de ocorrencia de ataques do tipo DoS, packet sniffing, ou
ARP spoofing. Ataques estes que podem levar ao comprometimento ou ao
mau funcionamento de sistemas e da rede informatica de uma instituicao.
Os mecanismos de seguranca tradicionais, como firewalls, IDS e IPS, tem
como objetivo a detec ao e prevencao de ataques informaticos e de outras
atividades maliciosas, sendo no entanto importante garantir a identificacao
e a autoria de tais ac
oes quando estas ocorram. Torna-se assim necessaria a
implementacao de mecanismos centralizados de autorizacao, autenticacao e
de controlo de acesso ` a rede que impecam que um utilizador nao autorizado
aceda a recursos da infraestrutura de rede cablada da ESTG, permitindo o
registo de toda a atividade de um utilizador autorizado.
A implementac ao do protocolo IPv6 na rede cablada da ESTG permitira

a ultrapassar as varias limitac
oes do protocolo IPv4, tais como a exaustao
dos enderecos IP publicos disponveis, obrigatoriedade de configuracao IP
manual ou por DHCP, inexistencia de mecanismos de seguranca nativos, e
um suporte QoS limitado. Alem disso, o IPv6 possui novas funcionalidades
como suporte a mobilidade, autoconfiguracao e aumento da sua extensibili-
dade. Ao nvel da seguranca, o protocolo IPSec, que fornece confidenciali-
dade, autenticac
ao e integridade dos dados, esta ja integrado no IPv6, bem
como outros mecanismos de seguranca.
O objetivo deste projeto e o da implementacao de mecanismos de auten-

ticacao na rede cablada utilizando 802.1X e a migracao da rede para IPv6.
Neste captulo sera descrita a solucao encontrada para a implementacao
desta solucao.
31
32 Rede ESTG/IPv6
4.1 Situa
cao atual
A atual estrutura de rede da ESTG esta segmentada em VLANs. Existe uma
VLAN por laborat orio da escola, outra para o centro de investigacao, outra
para a rede de servicos. A rede de administracao conta com DMZs, uma
VLAN para administracao de equipamentos, e uma VLAN para servicos
destinados aos laborat orios. As permissoes de acesso de cada VLAN sao
diferenciadas de acordo com a necessidade e funcionalidade de cada uma
delas.
Os computadores da instituicao ao servicos dos estudantes obrigam a
uma autenticac ao via LDAP. No entanto o servidor LDAP nao e gerido pela
ESTG, o que dificulta a sua manutencao e a consulta de logs. Na rede
cablada n ao existe controlo de acesso à rede, sendo possvel que qualquer
utilizador ligue os seu equipamento à rede cablada sem que exista qualquer
controlo. S ao disponibilizados varios servicos à comunidade (estudantes,
funcionarios, servicos, docentes), sendo os mais relevantes:
Servicos de rede (DNS, DHCP, VPN)
Portais web (ESTG, Moodle)
Servidor de ficheiros
Servico de impressao
Servico de reposic
ao de laboratorios
Disponibilizac
ao de servidores diversos para laboratorios
A Figura 4.1 representa a situacao atual de rede da ESTG. A ESTG

tem somente controlo da rede ate à firewall privada (Firewall-priv ) com o
endereco IP 172.20.5.7. Todos os servicos que existem apos esta firewall sao
da responsabilidade dos Servicos da Presidencia do Politecnico do Porto.
Nestes servicos incluem-se os servicos de rede: DHCP, LDAP, RADIUS
(para a rede eduroam), servico de logs, entre outros.
4.2 Requisitos
A an
alise do contexto atual levou a identificacao dos seguintes requisitos:
1. Autentica c
ao: Os utilizadores para terem acesso à rede da ESTG
por cabo dever ao fornecer as suas credenciais, como ja o fazem na
rede sem fios. A autenticacao devera ser efetuado num ponto central,
possibilitando assim a utilizacao das mesmas credencias para todos os
servicos.
33 Rede ESTG/IPv6
Figura 4.1: Diagrama atual da rede ESTG

.1 .254
.1 .254
.1
.254
DHCP Server Firewall - CheckPoint
.1
.11
.254
.1 .254
SP
.1 .254
.1 .254
193.136.56.99 .254
Firewall Privada Pfsense
2. Autoriza c
ao: Para que seja concedido acesso à rede cablada a um
utilizador, o mesmo dever
a ter autorizacao para tal.
3. Guest-Vlan: Dever a existir uma Guest-Vlan com redirecionamento

para uma p agina de instrucoes de configuracao. Esta pagina de con-
figurac
ao dever
a estar disponvel atraves da utilizacao da tecnologia
captive portal. Na guest-vlan serao disponibilizados servicos como a
ao de imagens de software 1 . A guest-vlan devera ter acessos
reposic
muito restritos nao permitindo aceder aos servicos da ESTG nem à
Internet.
4. Configura c
ao IP: A configuracao de enderecamento IP (IPv6) devera
ocorrer de forma automatica. A configuracao de enderecamento devera
ser do tipo stateful de forma a permitir o controlo da atribuicao de
enderecos IP. Para os servicos internos da ESTG o enderecamento
dever
a ser est
atico.
5. Roteamento: O tr afego com destino a redes IPv4 e IPv6 devera ser

corretamente encaminhado.
1
Servico disponibilizado atraves da utilizac
ao da ferramenta open-source FOG
34 Rede ESTG/IPv6
Figura 4.2: Diagrama funcional da proposta de solucao
Equitrack Site Moodle
Posto
Posto
Internet
Servios externos ESTGF
Posto
DHCP Server DNS Server Radius Server LDAP Server Log Server
6. DNS: A resoluc
ao de nomes IPV4 e IPv6 devera estar devidamente
configurada. Deverao ser introduzidas as alteracoes necessarias no
servidor DNS para que este suporte enderecos do tipo AAAA para a
rede interna.
7. Filtragem de tr afego: Devera estar definido um conjunto de regras

para eliminar ou aceitar trafego de rede. As regras de acesso deverao
ser definidas a semelhanca das polticas de acesso implementadas na
ESTG.
8. Registo de atividade: A atividade dos utilizadores na rede devera

ficar registada de forma centralizada. Todos os processos de login na
rede, atribuic
oes de endereco IP, acessos a servicos internos e acessos
a Internet dever
` ao ser registados.
4.3 Proposta de soluc

ao
A an alise do problema, quando enquadrada com o levantamento de requi-
sitos, apresentado na seccao 4.2, e com o estado da arte (Captulos 2 e 3)
pode-se concluir que a tecnologia 802.1X em conjunto com o IPv6, permi-
tem enderecar todos os requisitos identificados. A Figura 4.2 apresenta um
diagrama funcional da proposta de solucao que identifica as ferramentas
escolhidas para a implementacao.
Os servicos presentes na Figura 4.2, e que compoem a presente proposta
de solucao, s
ao:
35 Rede ESTG/IPv6
Equitrack - Software que permite a gestao dos custos de impressao

para as impressoras em servico na ESTG, funcionando como servidor
de impress
ao.
Site - Site institucional da ESTG a funcionar num servidor Centos 5.
Moodle - Software livre de apoio à aprendizagem, tendo como principal

funcionalidade a disponibilizacao de conte implemen-
udos didaticos. E
tado em PHP e utiliza base de dados MySql e servidor web apache.
Servidor DHCP - Necess ario para possibilitar a configuracao dinamica

de enderecamento IP, quer em IPv4 como em IPv6.
Servidor DNS - Reconfiguracao do servidor de DNS atual de forma a

incluir registos AAAA dos servicos internos.
Servidor RADIUS - Servidor de autenticacao para 802.1X e demais

servicos.
Servidor de logs - Servidor central de logs para efetuar registo de toda

a atividade de rede.
Active Directory - Servico que sera o ponto de autenticacao central

tanto para logins nos PCs da ESTG, como para o Servidor RADIUS
(LDAP). Este servico esta integrado com o Gestao Integrada de Re-
oes (GIRA)2 , permitindo manter o sincronismo de
cursos e Aplicac
contas de utilizador em todas as plataformas do Instituto Politecnico
do Porto (IPP).
Firewall - Para efetuar filtragem e roteamento de trafego de rede.

A solucao encontrada pode ser dividida em duas partes. Uma parte que
consiste na implementac ao de autenticacao, autorizacao e criacao de uma
guest-vlan na rede cablada (ver Seccao 4.3.1). A outra parte que consiste
na configuracao dos servicos associados ao IPv6, de que sao exemplo a con-
figuracao de IP, o roteamento, o servico de DNS e filtragem de trafego e o
registo de atividade na rede (ver Seccao 4.3.2).
4.3.1 802.1X
A implementac ao de 802.1X permite dotar a rede da ESTG de mecanismos
de autenticac
ao e autorizacao na rede cablada. Como descrito no captulo
2,um cenario de autenticac
ao com o 802.1X requer um suplicant, um authen-
ticator e um servidor de autenticacao. Na solucao proposta, o servidor de
2
O GIRA e uma plataforma centralizada desenvolvida pelos Servicos da Presidencia do
Instituto Politecnico do Porto que tem como funcionalidade principal a gest ao centralizada
dos utilizadores do Instituto Politecnico do Porto. Todas as contas de utilizador, bem como
as contas de email associadas, sao geridas pelo GIRA.
36 Rede ESTG/IPv6
Figura 4.3: Elementos da implementacao de 802.1X na ESTG
autenticacao ter
a uma AD como backend para autenticacao. A Figura 4.3
apresenta o esquema funcional da implementacao 802.1X na rede da ESTG.
Os elementos presentes na Figura 4.3 incluem um Desktop Pc e um Lap-
top como exemplos de equipamentos tipo supplicant, podendo no entanto
existir outros equipamentos como impressoras, switchs ou routers que po-
dem tambem assumir este tipo. Nos equipamentos da ESTG, os sistemas
operativos em uso s ao o Windows 10, o Fedora 24 e o MacOS ElCapitan.
Foram efetuados testes de configuracao nestes sistemas operativos que de-
monstraram a sua total compatibilidade com o protocolo 802.1X.
O authenticator e o equipamento de rede responsavel pela autenticacao
de um supplicant. Na Figura 4.3 este elemento e representado por um switch
HP Procurve 2610. Existem em funcionamento na rede da ESTG varios
equipamentos de rede de diferentes marcas, tais como: HP, 3COM, Dell e
Cisco. Foram analisados os varios equipamentos e constatou-se que todos
suportam o referido protocolo.
O servidor de autenticacao a usar e o FreeRadius. Este e o servidor
Radius open source mais comum. Suporta os protocolos de autenticacao
mais comuns, podendo vir com uma interface de gestao web desenvolvida
em PHP. E a base de muitos produtos RADIUS comerciais como sistemas
integrados, appliances com suporte NAC, entre outros [21]. Como backend
de autenticacao para o FreeRadius, foi implementado um Active Directory
2012 R2.
Um Active Directory (AD) e composto por um conjunto de servicos e
processos que permitem efetuar a gestao de um domnio, ou rede, e os seus
servicos relacionados com a gestao de identidade e de diretorio em sistemas
[42, 43]. E desenvolvido pela Microsoft e includo nos sistemas operativos
Windows Server. Um servidor com o servico Active Directory Domain Servi-
ces (AD DS) ativo e denominado de controlador de domnio. E responsavel
pela autenticacao e autorizacao de utilizadores e computadores numa rede
com domnio Windows. O AD e responsavel pela gestao e implementacao
de polticas de seguranca, pela instalacao e atualizacao de software [44],
37 Rede ESTG/IPv6
Tabela 4.1: VLANs em uso

Perfil de utilizador VLAN
Gestao 601
Guest-vlan 649
Laborat orio 650
permite a gest ao e armazenamento de informacao de administracao, fornece

mecanismos de autenticac ao e autorizacao para outros servicos relacionados
tais como AD Certificate Services, AD Federated Services entre outros. O
AD utiliza o LDAP vers ao 2 e 3, uma versao do Kerberos desenvolvida pela
Microsoft e DNS.
Um AD pode ser tambem implementado recorrendo a software livre in-
dependente das plataformas da Microsoft. O samba e um software livre que
fornece servicos de impress ao e de ficheiros para cliente Windows, e que pode
efetuar a implementac ao de um AD. Na sua versao 4 suporta AD e domnios
Windows NT [59].
No caso da ESTG, a implementacao de um AD utilizando samba foi
implementada no ambiente de testes, tendo tido obtidos resultados satis-
fatorios. No entanto a soluc ao escolhida recaiu num AD em Windows pois
pretendia-se que existisse integrac ao e sincronizacao de contas entre o LDAP
gerido pelos servicos da presidencia e o sistema de autenticacao local, o que
so e possvel com a utilizacao de uma AD local.
Outro requisito desta soluc ao e a existencia de uma guest-vlan a que foi
atribudo o ID 649. Esta ser a a VLAN onde os utilizadores nao autenticados
serao colocados pois ter a o acesso limitado ao servico DNS e de autenticacao.
No gateway desta VLAN, e configurado um captive portal que apresenta as
instrucoes de configurac ao a seguir pelos utilizadores para terem acesso à
rede. Ap os autenticac
ao na rede, os clientes serao entao colocados na VLAN
normal, a VLAN com ID 650. O captive portal e implementado com recurso
à appliance Pfsense (ver Secc ao 4.3.2). As restantes VLANs em uso podem
ser consultadas na Tabela 4.1
4.3.2 IPv6
Para a implementac ao de IPv6 na rede da ESTG foram definidos como requi-
sitos a configurac
ao autom atica e central de enderecamento IP, a existencia
de mecanismos de resoluc ao de nomes IPv4 e IPv6, o roteamento e a filtra-
gem de tr afego. O cumprimento destes requisitos implica algumas alteracoes
de servicos existentes e a implementacao de novos servicos. O servico de DNS
necessita de ser reconfigurado de modo a incluir registos do tipo AAAA,
e necess aria a configuracao de servico DHCPv6, e necessario implementar
servicos de roteamento e filtragem de trafego, e por u ltimo, nao tendo a ver
com IPv6 mas com toda a soluc ao, e necessaria a configuracao de servico
38 Rede ESTG/IPv6
que permita o registo de atividade na rede.
DNS
O servico de DNS e um sistema hierarquizado e descentralizado responsavel
pela resoluc
ao de nomes. O RFC 3596 [64] define as alteracoes necessarias ao
DNS para que este seja dotado de suporte para IPv6. As alteracoes incluem
a criac
ao de um tipo de registo para gravar enderecos IPv6, a definicao do
domnio para pesquisas IPv6 e de novas definicoes dos tipos de query que
retornam enderecos de Internet.
A ferramenta escolhida para efetuar a resolucao de nomes e o BIND,
uma vez que e o servidor DNS em producao na ESTG. Berkeley Internet
Name Domain (BIND) e um software open-source que implementa o pro-
tocolo DNS, sendo o software de DNS mais utilizado na Internet [30]. E
uma referencia na implementacao do DNS mas tambem um software para
ambientes de producao adequado para cenarios com grande utilizacao e que
necessitem de alta disponibilidade. A implementacao inicial do BIND foi
feita na Universidade de Berkeley na California em 1980. O BIND possui
muitas funcionalidades entre as quais suporte para Domain Name System Se-
curity Extensions (DNSSEC) e os protocolos Transaction SIGnature (TSIG)
e IPv6. Tem tambem suporte para DNS64 (ver Captulo 3.2.3). Foram defi-
nidos novos tipos de registos, os registos AAAA, que sao capazes de guardar
um registo IPv6 ou um domnio IP6. As querys existentes foram alteradas
de forma a suportarem tambem procuras de registos do tipo A e do tipo
AAAA.
No caso concreto da ESTG, o atual servico de DNS foi reconfigurado para
aceitar e responder a querys IPv6, bem como foram inseridos os registos do
tipo AAAA referentes aos servicos internos implementados em IPv6.
DHCPv6
Para a configuracao automatica de endereco IP e necessario recorrer ao
protocolo Dynamic Host Configuration Protocol version 6 (DHCPv6). O
DHCPv6 e um protocolo definido pelo RFC 3315 no ano de 2011 [19], utili-
zado em IPv6 para efetuar a configuracao dos hosts com enderecos e prefixos
IP, sendo o equivalente para IPv6 do DHCP para IPv4 [19].
O DHCPv6 pode ser utilizado tanto para a atribuicao de enderecos IP
para clientes que utilizem statefull configuration, como para a configuracao
de informacao, que n
ao endereco IP para clientes que utilizem stateless au-
toconfiguration, operando em UDP na porta 546 para clientes e 547 para os
servidores. Para um cliente obter um endereco IP, este utiliza um identifica-
dor u
nico chamado de DHCP Unique Identifier (DUID). Este identificador,
definido no RFC 3315 [19] e pelo RFC 6355 [48], pode conter informacao
de tres tipos: endereco fsico da placa de rede, endereco fsico e tempo ou
39 Rede ESTG/IPv6
Tabela 4.2: Servicos de rede permitidos

Porta Servi co Destino
80 HTTP Internet + Servidores Internos
443 HTTPS Internet + Servidores Internos
993 IMAPS Internet
995 POPS Internet
587 SMTP Internet
4070 Spotify Internet
2049 NFS Internet
22 SSH Internet
5222 XMPP Internet
5223 Apple Push Notification Service Internet
123 NTP Internet
465 SMTPS Internet
25 SMTP Internet
143 IMAP Internet
53 DNS Servidor DNS interno
139 NetBIOS Session Service servidores internos
445 SMB servidores internos
identificador u
nico baseado no fabricante.
O servico de DHCPv6 foi implementado recorrendo novamente à appli-
ance Pfsense, sendo utilizado o modo de configuracao stateful.
Roteamento e filtragem de tr
afego
A filtragem de trafego e mais um dos requisitos identificados. E pretendido

que os utilizadores apenas tenham acesso a certos servicos e redes, tanto
internos como externos, ` a semelhanca das polticas de acesso implementadas
e em funcionamento para IPv4. Assim, somente o acesso a alguns servicos
externos sao permitidos, e o acesso aos servicos internos e tambem controlado
de acordo com o servico (porta) e IP de destino. Na Tabela 4.2 podemos
ver quais os acessos permitidos aos utilizadores locais ligados a uma VLAN
de acesso normal. O roteamento de trafego entre as redes internas e a
Internet e necess
ario para que seja possvel comunicar entre estas redes. A
apliance pfsense permite cumprir com ambas as funcionalidades de filtragem
de trafego e roteamento.
A pfsense assenta numa distribuicao baseada em FreeBSD com um ker-
nel adaptado e com software de terceiros que lhe adiciona funcionalidades
extra [53]. E principalmente orientada para ser utilizada como firewall e
router, sendo adequada para instalacoes em PCs, tendo tambem solucoes
para instalar em hardware especfico. Fornece muitas das funcionalidades
40 Rede ESTG/IPv6
presentes nas firewalls comerciais como Check Point, Cisco, Juniper, So-
nicwall, Netgear, Watchguard, entre outras. Inclui um interface web para
configurac
ao de todos os seus componentes, nao sendo necessaria qualquer
configurac
ao por linha de comandos. Entre as funcionalidades principais
incluem-se firewall, routing, NAT, balanceamento de carga, captive portal,
servidor de DHCP, DNS dinamico, qualidade de servico e VPN [2].
Alem destas funcionalidades base, existem muitas outras ferramentas que
podem ser instaladas atraves do gestor de pacotes e que permitem expan-
dir a sua funcionalidade. Entre estas ferramentas podem ser citadas como
exemplo o squid, o nmap, o snort, o bind, o open-vm-tools, o quagga OSPF,
entre outras.
Registo de atividade
O registo de atividade ou logging consiste em registar tudo o que se passou
numa rede de computadores. Uma boa gestao dos logs recolhidos permite
a identificac
ao de potenciais problemas antes que estes ocorram. Existem
muitas fontes de dados, sendo os principais os ficheiros de logs de servidores
e de aplicac
oes, do tr
afego de rede, informacoes do perfil de utilizadores nos
PCs e switchs de rede.
A principal funcao de um servidor de logs e a recolha de dados de varios
dispositivos e consolida-los num u nico local onde possam ser monitorizados,
pesquisados e analisados. O servidor de logs atua como um ponto central
das atividades de logs onde todos os logs da rede podem ser armazenados.
O servidor de logs e de grande importancia para a seguranca de uma rede
pois sem ele os logs ficariam dispersos em varios dispositivos dificultando a
sua analise e arquivo.
O registo de atividade foi implementado utilizando o software opensource
Rsyslog. Rsyslog e uma ferramenta open-source utilizada em sistemas Unix
que permite o encaminhamento de mensagens de log numa rede IP. Rsyslog
utiliza o protocolo syslog, definido no RFC 3164 [38], adicionando algu-
mas funcionalidades extra como: timestamp, nome do host e do servico de
origem, filtros baseados em conte udo, configuracao do formato de output,
possibilidade de escrita para motores de bases de dados, usa o TCP como
modo de transporte, operacao multi-threaded, Secure Sockets Layer (SSL),
TLS, Reliable Event Logging Protocol (RELP) [57].
4.4 Conclus
ao
A rede da ESTG operava, inicialmente, apenas em IPV4 e sem autenticacao
para acessos `
a rede por cabo. Esta proposta de solucao permite dotar a
rede da ESTG de autenticacao para todos os acessos, independentemente do
meio utilizado (cabo, sem fios), e de suporte ao funcionamento simultaneo
IPv4 e IPv6. A autenticacao assentou na utilizacao do protocolo 802.1X.
41 Rede ESTG/IPv6
A implementac ao de um servidor RADIUS que por sua vez tera um Active

Directory como backend para autenticacao, permite manter um ponto u nico
de autenticacao com 802.1X.
A operacao em IPv6 implica a instalacao de novos servicos e a recon-
figuracao de alguns servicos j
a existentes. O equipamento base para esta
operacao em IPv6 e a appliance pfsense que implementa o DHCPv6, o rote-
amento IPv6 e firewall. Para o servico de DNS foi escolhido o BIND e para
o registo de logs o RSyslog.
42 Rede ESTG/IPv6
Captulo 5
Avalia
c
ao do trabalho
Apos a especificac
ao da proposta de solucao constante do Captulo 4, construiu-
se um primeiro ambiente laboratorial (ver Figura 5.1) para testar os com-
ponentes anteriormente identificados. O ambiente de testes tambem permi-
tiu afinar as configuracoes a aplicar nos varios equipamentos. O ambiente
de testes montado e composto por tres PCs, um switch HP Proliant, e
tres maquinas virtuais alojadas num servidor de virtualizacao Vmware. As
maquinas virtuais foram configuradas com 2 GB de memoria RAM, 16GB
de disco rgido e um processador virtual. O sistema operativo utilizado foi
o Centos 6 em instalac ao mnima.
Numa das m aquinas virtuais foi instalado o FreeRadius com o objetivo
se ser o servidor de autenticac
ao para acessos 802.1X. Noutra maquina vir-
tual, foi instalado o BIND, compilado manualmente com a opcao configure
enable-filter-aaaa. Esta confifuracao permite a utilizacao da opcao filter-
aaaa-on-v4 yes do BIND que limita a resposta a pedidos com origem em
enderecos IPv4 a registos tipo A. Foi ainda utilizada uma terceira maquina
virtual, onde foi instalado o samba (versao 4) para servir como backend
de autenticacao para o FreeRadius. Este servico foi testado para servir de
ponto unico de autenticac
ao da instituicao, tendo sido posteriormente pre-
terido por um servidor com Active Directory.
Os PCs utilizados foram tres HPs dc5800 Dual Core a 3 GHZ com 4
GB de RAM. No primeiro PC foi instalada a appliance Pfsense, para servir
as funcoes de roteamento, filtragem de trafego e DHCPv6. No segundo PC
foi instalado o sistema operativo Centos. Adicionalmente foram instalados
varios servicos para testar a conetividade IPv6 dentro da rede local, tais
como HTTP e SSH. Neste segundo PC, foi tambem instalado o Rsyslog
para se testar o funcionamento dos logs. No terceiro PC, foi instalado o
sistema operativo Centos e o software Tayga, que e uma implementacao de
NAT64.
43
44 Avaliacao do trabalho
Figura 5.1: Esquema funcional do ambiente de testes
DNS IPv4 Samba4
NAT64
DNS64
Cliente
RADIUS
Servios
Cliente
Pfsense
NAT64 - Tayga
Uma limitac ao para o desenvolvimento deste projeto foi a disponibilizacao

tardia de conetividade com a Internet por IPv6. Esta so ficou operacional
no dia 1 de Agosto. O desenvolvimento dos testes necessarios com objetivo
da elaboracao do prototipo requereu a exploracao de alternativas no que
respeita `
a conetividade IPv6. Tendo em conta as tecnologias de transicao
abordadas em 3.2.3, foi implementado um mecanismo de traducao para per-
mitir a conetividade com a rede local e com a Internet. O mecanismos de
traduc
ao implementado foi o Tayga.
O Tayga e uma implementacao NAT64 stateless para Linux que utiliza
drivers TUN para traduzir IPv4 para IPv6 [37]. A utilizacao de NAT64 com
DNS64 e com o servidor de DNS com a opcao filter-aaaa-on-v4 yes permite
que uma rede IPv6 tenha conetividade com a Internet IPv4. A Listagem
5.1 mostra a diferenca entre um pedido de resolucao de nomes normal e um
utilizando DNS64. No primeiro pedido e retornado um endereco IPv4, no
segundo e retornado um endereco IPv6, com o prefixo 2001:690:23c0:ffff::.
Este prefixo e definido nas configuracoes do DNS e pertence à rede local.
De referir que o equipamento eu.ipp.pt nao tem endereco IPv6, pelo que
o endereco retornado e alterado pelo DNS64 para que possa utilizado numa
rede IPv6.
Listagem 5.1: Resolucao de nomes utilizando DNS64

1 [ r o o t @ l o c a l h o s t ]# n s l o o k u p eu . i p p . pt
2 Server : 172.20.6.100
3 Address : 172.20.6.100#53
4 Nona u t h o r i t a t i v e answer :
5 Name : eu . i p p . pt
6 Address : 1 9 3 . 1 3 6 . 5 6 . 1 9 4
7
8 [ r o o t @ l o c a l h o s t ]# n s l o o k u p query=AAAA eu . i p p . pt
9 Server : 2 0 0 1 : 6 9 0 : 2 3 c0 : 2 0 5 0 : : 1
10 Address : 2 0 0 1 : 6 9 0 : 2 3 c0 : 2 0 5 0 : : 1 # 5 3
12 eu . i p p . pt has AAAA a d d r e s s 2 0 0 1 : 6 9 0 : 2 3 c0 : f f f f : :
c188 : 3 8 c2
O ficheiro de configurac ao do Tayga esta disponvel no Apendice A.1.

Ja o script de inicializac
ao do mesmo, onde podemos constatar que a sua
configurac
ao e bastante simples, esta disponvel no Apendice A.2.
5.1 Solu
c
ao Final
A Figura 5.2 apresenta a estrutura final da rede da ESTG, apos a imple-
mentac
ao da presente proposta de solucao. Pode-se ver os varios servicos que
foram implementados, ou alterados, para suportarem o seu funcionamento
em IPv6, com autenticacao 802.1X.
Figura 5.2: Diagrama final da rede ESTG com suporte IPv6/802.1X
Equitrack Site Moodle

(existente) (reconfigurado) (reconfigurado)
Posto
Posto
Internet
Servios externos ESTGF
Posto
DHCP Server DNS Server Radius Server Active Directory Log Server
(novo) (reconfigurado) (novo) (novo) (novo)
Servidor de Autentica
cao
Como servidor de autenticacao foi implementado o FreeRadius, na sua versao
3.0.4, numa m aquina virtual com 2 GB de memoria RAM, 16 GB de disco
rgido, 1 core, a correr o sistema operativo CentOS Linux versao 7.2.1511
(Core). Como backend de autenticacao, foi implementado um Active Di-
rectory Windows 2012 R2 integrada com o servidor LDAP dos Servicos da
Presidencia. Este LDAP dos Servicos da Presidencia e o ponto central para
a gestao de contas de todos os utilizadores do IPP.
O servidor FreeRadius foi ainda configurado para suportar o PEAP como
modo de autenticac ao de clientes. Para tal foi necessario ativar o modulo
LDAP, configurado com os dados da AD, configurar os certificados, para
que este comunique por SSL, e ativar os modulos EAP e MSCHAP.
Para que o FreeRadius aceite pedidos de autenticacao de clientes foi ne-
cessario alterar o ficheiro de configuracao clients.conf (Listagem D.6). Para
cada cliente e necessario configurar o seu nome, endereco IP e uma password
que ser a utilizada no processo de autenticacao entre authenticator e servidor
de autenticac ao.
Authenticator
A implementac ao de 802.1X em rede cablada implica que os authenticators
sejam switches Ethernet. Este devem ainda efetuar a atribuicao dinamica de
VLANs. Deve existir uma guest-vlan e uma VLAN especfica para a gestao
dos equipamentos ativos de rede, seguindo as praticas em uso na ESTG.
As VLANs utilizadas no prototipo sao indicadas na Tabela 4.1. Alguns dos
switchs utilizados n
ao suportam enderecamento IPv6, pelo que a VLAN de
gest
ao foi mantida em IPv4. O servico de reposicao de imagens utilizado
(Fog) tambem n ao possui suporte para IPv6. Tal levou a que a guest-vlan,
que tem um conjunto de acessos muito restritos, tivesse de ser mantida
unicamente em IPv4.
Listagem 5.2: Passos para a configuracao de autenticacao num switch HP

Proliant
1 ProCurve Switch 261048# r a d i u s s e r v e r h o s t 1 7 2 . 2 0 . 6 . 3 key

2 ProCurve Switch 261048# aaa a u t h e n t i c a t i o n port a c c e s s eap
radius
3 ProCurve Switch 261048# aaa port a c c e s s a u t h e n t i c a t o r A1A48
unauthv i d 649
authv i d 650
c l i e n t l i m i t 1
7 ProCurve Switch 261048# aaa port a c c e s s a u t h e n t i c a t o r a c t i v e
8 ProCurve Switch 261048# w r i t e mem
A configuracao de um authenticator requer varios passos. Em primeiro

lugar e necess
ario criar as v
arias VLANs e atribuir-se um endereco IP ao
switch. De seguida, e necessario configurar o processo de autenticacao, de-
finindo o servico de autenticac
ao como RADIUS e ativando a autenticacao
802.1X nas portas pretendidas. Na Listagem 5.2 podem-se ver os passos
de configurac
ao utilizados. A linha 1 define o endereco IP do servidor RA-
DIUS, bem como a password a utilizar pelo equipamento. A linha 2 ativa
o modo de autenticac ao eap-radius no switch. As linhas 3,4 e 5 ativam a
autenticac
ao nas portas do switch, definem as VLANs para utilizadores nao
autorizados (guest-vlan) e autorizados. A linha 6 define o limite de clientes
por porta como um. Esta u ltima opcao serve para evitar que um utilizador
consiga ligar uma m aquina virtual em modo brigde (com um novo endereco
MAC) e assim obter um segundo endereco IP que nao estaria associado ao
login efetuado anteriormente. Por fim toda a configuracao e ativada.
Supplicant
O supplicant, como referido anteriormente, e a parte do software 802.1X
que executa no cliente. De uma forma generica, e para a generalidade dos
dispositivos e aplicacoes, a configuracao de um dispositivo para que este
possa utilizar 802.1X resume-se aos seguintes passos: em primeiro lugar e
necessario ativar a autenticac
ao 802.1X no dispositivo, de seguida escolher o
metodo de autenticacao e por fim introduzir as credenciais do utilizador. Se
as credenciais introduzidas estiverem corretas e se o utilizador estiver auto-
rizado a aceder à rede, o dispositivo e colocado na VLAN correta e recebera
as respetivas configuracoes de rede necessarias para a comunicacao. No ser-
vidor RADIUS ser a registada uma mensagem a reportar a autenticacao com
sucesso deste cliente. As configuracoes manuais 802.1X para os sistemas
operativos Windows, Fedora e MacOS e apresentada no Apendice C.
Listagem 5.3: Script para autenticacao 802.1X em Fedora
1 #!/ b i n / bash
2 s e d i s , \ ( IEEE 8021X IDENTITY=\) . , \ 1 $USERNAME , / e t c /
s y s c o n f i g / networks c r i p t s / i f c f g P r o f i l e 1
3 n m c l i c o n n e c t i o n down i d Wired c o n n e c t i o n 1
4 n m c l i c o n n e c t i o n up i d P r o f i l e 1
5 s e r v i c e NetworkManager r e s t a r t
Nos computadores dos laboratorios da ESTG a configuracao do 802.1X

e autom atica. Para tal, em sistemas operativos Windows, recorreu-se ao
servico Wired Auto Config e ` a configuracao das placas de rede para que
estas, em 802.1X, utilizem as credenciais de login na maquina como cre-
denciais de autenticac
ao na rede (todos os PCs dos laboratorios estao num
domnio AD). Em sistemas Linux a configuracao e mais complexa ja que,
embora tambem estejam no mesmo domnio AD, nao e possvel utilizar
as credenciais de login para efetuar autenticacao na rede, nem e possvel
efetuar-se esta configuracao de forma automatica para todos os utilizadores.

Assim, a soluc ao passou pelo desenvolvimento de um script, configurado
para executar no momento do login dos utilizadores, que procede à confi-
gurac
ao da rede. Como desvantagem, este script requer a introducao da
password do utilizador. O script e apresentado na Listagem 5.3.
Em cen arios de utilizacao de computadores pessoais com sistema ope-
rativo Windows por parte dos utilizadores da ESTG, foi desenvolvido um
executavel que procede de forma automatica à configuracao das definicoes de
rede necess arias para a ligacao. Este executavel contem um script que inicia
os servicos necessarios e que importa o perfil de rede, sendo so necessario a
introducao das credenciais. Este executavel esta disponvel no Captive Por-
tal, podendo ser descarregado por qualquer utilizador. No Captive Portal
est
a tambem disponvel uma pagina com os procedimentos de configuracao
para os sistemas operativos mais usuais.
Guest-vlan e Captive Portal

Um dos requisitos implica a existencia de uma guest-vlan a atribuir a todos
os equipamentos antes de estes serem autenticados e autorizados. Aprovei-
tando a existencia da guest-vlan, alguns servicos foram configurados para
poderem ter um comportamento mais amigo do utilizador. Um caso e o
do acesso ao servidor de domnio (AD), que ao ser permitido na guest-vlan
permite que os utilizadores possam efetuar login no sistema operativo dos
computadores da ESTG antes de existir autenticacao 802.1X. Outro caso e
o do sistema de reposicao de imagens (FOG) nos computadores dos labo-
rat
orios da ESTG. Tal deve-se ao facto do FOG nao ser compatvel nem com
802.1X nem com com IPv6. A gama de enderecos 10.0.0./24 foi a escolhida
para a guest-vlan.
Quando um utilizador nao autorizado tenta aceder aos recursos de rede,
este e dirigido para o Captive Portal. A pode consultar instrucoes para
efetuar as configurac
oes de rede que deve utilizar. O Captive Portal e dis-
ponibilizado pela Pfsense, o gateway da rede, que funciona redirecionando
todo o tr afego com destino às portas 80 e 443 para a pagina web de con-
figurac
ao. Esta pagina de configuracao (ver Apendice E) e muito simples,
apresentando somente as instrucoes de configuracao para os principais sis-
temas operativos.
Endere
camento IP
O enderecamento IP foi efetuado de acordo com o esquema de enderecamento
apresentado na Tabela 5.1, onde estao definidas as redes IPv6 das VLANs e
laborat
orios existentes na ESTG. Este esquema de enderecamento foi defi-
nido de forma a permitir a manutencao da divisao em VLANs ja existente.
Pode ver-se, na primeira linha, uma gama de enderecos reservada à inter-
Tabela 5.1: Esquema de enderecamento IPv6

Enderecamento IPV6 Enderecamento IPV4 Rede
2001:690:23c0:2000::/64 Reservado SP
2001:690:23c0:2001::/64 172.20.5.0 DMZ
2001:690:23c0:2002::/64 172.20.6.0 DMZ-Internal
2001:690:23c0:2003::/64 172.20.10.0 SRV-LAB
2001:690:23c0:2010::/64 172.20.100.0 LAN
2001:690:23c0:2011::/64 172.20.101.0 LAB P4
2001:690:23c0:2012::/64 172.20.102.0 LAB 1.5
2001:690:23c0:2013::/64 172.20.103.0 LAB 0.1
2001:690:23c0:2014::/64 172.20.104.0 LAB P6 (desativado)
2001:690:23c0:2015::/64 172.20.105.0 LAB 0.3
2001:690:23c0:2016::/64 172.20.106.0 Projecao
2001:690:23c0:2017::/64 172.20.107.0 LAB P7
2001:690:23c0:2018::/64 172.20.107.0 LAB P8
2001:690:23c0:2019::/64 172.20.107.0 LAB P9
2001:690:23c0:2020::/64 172.20.107.0 LAB P10
2001:690:23c0:2021::/64 172.20.108.0 LAB P11
2001:690:23c0:2030::/64 172.20.109.0 CIICESI
ligacao e implementacao de servicos de rede da responsabilidade dos Servicos

da Presidencia do Instituto Politecnico do Porto, sendo seguida pelas duas
DMZ ja existentes, afetas aos servidor da ESTG, e das restantes redes que
correspondem ao laborat orios da ESTG.
A configurac ao do enderecamento IPv6 dos equipamentos pertencentes
às redes DMZ foi efetuada de forma estatica, ja que se tratam de servicos
acessveis interna e externamente. No prototipo e para a rede de clientes
(LAB01) foi utilizado o DHCPv6, tal como especificado nos requisitos da
solucao. Os enderecos atribudos às interfaces da Pfsense pode ser visto
na Figura 5.3. A interface WAN tem um endereco na rede reservada aos
Servicos da Presidencia (SP) por ser o interface de interligacao entre a rede
local da ESTG e a rede dos SP que permite o acesso à Internet. O interface
administrac ao serve somente para se poder aceder à configuracao da Pfsense
pela rede IPv4 de ESTG, n ao tendo nenhuma funcionalidade alem desta. O
interface guest-vlan, como o nome indica, permite o acesso restrito a guest-
vlan e e onde est a configurado o Captive Portal. O interface DMZ tem
somente um endereco IPv6 que permite tanto o acesso aos servicos da DMZ
como aos servidores web. O interface DMZINTERNAL tem enderecamento
IPv6 e IPv4 para permitir o acesso por IPv4 ao servidor DNS e à AD. Por
ultimo, o interface LAB01, onde estao os clientes, esta tambem implemen-
tado em dual stack, uma vez que os clientes possuem endereco IPv4 e IPv6
de forma a permitir o acesso tanto a servicos IPv4, como IPv6.
Figura 5.3: Enderecamento das interfaces da Pfsense
Na Pfsense o servico DHCPv6 tem que ser ativado e configurado em

todos os interfaces em que se pretenda a utilizacao do servico. A confi-
gurac
ao do servico DHCPv6 consiste em indicar a sub-rede e mascara de
rede, a extens
ao de enderecos disponvel, o prefixo, servidor de DNS e outros
par
ametros opcionais. Podemos ver na Figura 5.4 a configuracao DHCPv6
do interface LAB01, com os parametros descritos.
Figura 5.4: Configuracao DHCPv6 na pfsense
Roteamento
Os Router Advertisements (RA) anunciam prefixos a utilizar numa rede

IPv6 e permitem a identificacao dos routers disponveis na rede. Estes sao
configuradas em cada interface e funcionam em conjunto com o DHCPv6.
Uma vez que em DHCPv6, o endereco do gateway da rede nao e anunci-
ado, estes s ao anunciados atraves de RA. O Router Advertisement Dae-

mon (RADVD) foi o utilizado para a implementacao de RA, ja que este
esta includo na Pfsense. O daemon RADVD foi utilizado em conjunto com
o DHCPv6. A configurac ao do RADVD para uma rede local consiste na
ativacao do servico, como se pode ver na Figura 5.5. Quando ativo, vai-se
anunciar como sendo o default gateway.
Figura 5.5: Configurac

ao do RADVD para uma rede local
Resolu
cao de nomes
O servidor de DNS da ESTG foi reconfigurado para responder a querys IPv6,
bom como foram inseridos os registos do tipo AAAA referentes aos servicos
internos implementados em IPv6. Foi configurado o IP 2001:690:23c0:2002::2/64
no interface de rede do servidor DNS e as as opcoes listen-on-v6e query-
source-v6 port 53no ficheiro named.conf. Foi criada uma zona com registos
AAAA referentes aos servicos internos da ESTG, como podemos ver na
Listagem 5.4.
Listagem 5.4: Ficheiro de zona do BIND

1 @ IN SOA dns01 . i n t r a . e s t g . i p p . pt . (
2 201610281255; s e r i a l
3 28800; refresh , seconds
4 7200; retry , seconds
5 604800; expire , seconds
6 86400 ) ; minimum , s e c o n d s
7 IN NS dns01 . i n t r a . e s t g . i p p . pt . ;
8 moodle IN A 172.20.5.4
9 moodle IN AAAA 2 0 0 1 : 6 9 0 : 2 3 c0 : 2 0 0 1 : : 4
10 www IN A 193.136.58.218
11 gae IN A 172.20.5.17
12 www. gae IN A 172.20.5.17
13 gae IN AAAA 2 0 0 1 : 6 9 0 : 2 3 c0 : 2 0 0 1 : : 6
14 www. gae IN AAAA 2 0 0 1 : 6 9 0 : 2 3 c0 : 2 0 0 1 : : 6
15 www. gae IN A 172.20.5.17
16 intranet IN A 172.20.5.3
17 www. i n t r a n e t IN A 172.20.5.3
18 intranet IN AAAA 2 0 0 1 : 6 9 0 : 2 3 c0 : 2 0 0 1 : : 3
19 www. i n t r a n e t IN AAAA 2 0 0 1 : 6 9 0 : 2 3 c0 : 2 0 0 1 : : 3
Figura 5.6: Aliases na pfsense
Figura 5.7: Regras de firewall na pfsense
Filtragem de tr
afego
A Pfsense, vers ao 2.3.2 - community edition, foi o software de firewall se-
lecionado. Esta e a principal funcionalidade da Pfsense embora esta seja
utilizada para outras funcoes. As permissoes de acesso foram definidas à
semelhanca das polticas de acesso implementadas e em funcionamento para
IPv4, tal como j a foi referido no captulo 4 e se pode ver na Tabela 4.2.
A criacao de regras de firewall e feita utilizando o interface grafico de
f
acil utilizac
ao. Para simplificar a criacao de regras existe a possibilidade de
criac
ao de aliases, que permitem a criacao de conjuntos de portas, enderecos
IP ou URLs de forma a serem utilizados nas regras de firewall. Tal evita
a criac
ao de uma regra individual para cada porta ou endereco IP, por
exemplo. Pode-se ver na Figura 5.6 a lista de aliases criados, neste caso
conjuntos de portas. Na Figura 5.7 sao mostrados as regras de firewall
criadas para a rede interna.
Em todas as regras de firewall foi ativada a opcao de logging para que
seja possvel efetuar o registo de toda a atividade de rede, sendo possvel
desta forma a consulta dos acessos e tentativas de acesso efetuados na rede.
O registo de atividade e efetuado utilizando o servico Rsyslog. Para tal
foi utilizada uma m
aquina virtual com Centos 7.2. A maquina virtual tem
1 CPU, 2 GB de mem oria RAM e 60 Gb de disco rgido. A instalacao do

Rsyslog e efetuada atraves do comando yum install rsyslog. As configuracoes
para que os logs passem a ser enviadas para o Rsyslog sao efetuadas nos
clientes. No servidor Radius, na firewall Pfsense, no servidor de DNS e no
servidor de AD. Nas m aquina Linux, a configuracao e feita adicionando no
ficheiro rsyslog.conf a seguinte linha *.* @172.20.6.4 . Na Pfsense
existe uma opc ao situada em Status/System Logs/Settings onde podemos
ativar e configurar os logs remotos(ver Figura 5.8).
Figura 5.8: Configurac

ao de Logs remotos na Pfsense
Com a centralizacao dos logs, e possvel cruzar a analise de logs prove-

nientes de varios servicos. Por exemplo podemos verificar a autenticacao
802.1X de um cliente (RADIUS), verificando o nome de utilizador e o en-
dereco MAC da sua placa de rede, de seguida, podemos saber qual o foi
endereco IP (atraves do DUID) que lhe foi atribudo, que querys de DNS
efetuou, entre outras possibilidades.
5.2 Testes efetuados

Apos a conclus
ao da implementacao de todos os servicos necessarios, foram
efetuados multiplos testes para verificar o correto funcionamento de todos
os componentes e se se correspondia a todos os requisitos identificados.
Servidor de Autentica
cao
No servidor de autenticac ao foram efetuados varios testes. Em primeiro
lugar foi testada a autenticac
ao Windows Challenge/Response (NTLM) em
conjunto com o servidor RADIUS para aferir se os acessos à AD estavam
corretamente configurados. Na Listagem 5.5 pode-se ver um exemplo de um
teste de autenticac
ao efetuado com sucesso.
Listagem 5.5: Teste de autenticacao utilizando NTLM

1 [ r o o t @ r a d i u s ]# n t l m a u t h r e q u e s t ntkey domain=ad . e s t g . i p p
. pt username=jgmf
2 Password :
3 NT STATUS OK : S u c c e s s ( 0 x0 )
De seguida testou-se a autenticacao utilizando o radtest, uma ferramenta

que permite testar servidores FreeRadius efetuando pedidos diretamente a
este. Tal permite testar a configuracao do servidor RADIUS. A Listagem
5.6 mostra o resultado de mais um teste com sucesso.
Listagem 5.6: Teste de autenticacao utilizando radtest

1 [ r o o t @ r a d i u s ]# r a d t e s t t mschap jgmf 1 2 7 . 0 . 0 . 1 : 1 8 1 2 0
0 testing123
2 Sending AccessRequest Id 41 from 0 . 0 . 0 . 0 : 5 3 5 8 2 t o
127.0.0.1:18120
3 UserName = jgmf
4 NASIPAddress = 1 2 7 . 0 . 0 . 1
5 NASPort = 0
6 MessageA u t h e n t i c a t o r = 0 x00
7 MSCHAPC h a l l e n g e = 0 x 6 7 5 7 5 c 2 4 c 7 a 6 9 c 4 c
8 MSCHAPResponse = 0 x0001000000000000000000000000000000
9 0000000000000000004
ff61d30c0bfd0a93fa024263123a7c501200199fa2ebb93
10 R e c e i v e d AccessAccept Id 41 from 1 2 7 . 0 . 0 . 1 : 1 8 1 2 0 t o
1 2 7 . 0 . 0 . 1 : 5 3 5 8 2 l e n g t h 20
Authenticator
Existem alguns comandos que permitem a visualizacao das opcoes de confi-
gurac
ao e do estado da autenticacao de um authenticator. No caso da HP,
os comandos show authentication, show accounting e show radius permi-
tem visualizar os dados da autenticacao, da contabilizacao (nao utilizada
neste projeto) e do servidor RADIUS. Podemos visualizar na Listagem 5.7
o output destes comandos no switch utilizado para o prototipo.
Listagem 5.7: Comandos para visualizacao do estado do authenticator

1 ProCurve Switch 261048# show a u t h e n t i c a t i o n
2
3 S t a t u s and Counters A u t h e n t i c a t i o n I n f o r m a t i o n
4
5 Login Attempts : 3
6 Respect P r i v i l e g e : Disabled
7
8 | Login Login Enable Enable
9 A c c e s s Task | Primary Secondary Primary Secondary
10 +
11 Console | Local None Local None
12 Telnet | Local None Local None
13 PortA c c e s s | EapRadius None
14 Webui | Local None Local None
15 SSH | Local None Local None
16 WebAuth | ChapRadius None
17 MACAuth | ChapRadius None
18
19
20 ProCurve Switch 261048# show a c c o u n t i n g

21
22 S t a t u s and Counters Accounting I n f o r m a t i o n
23
24 I n t e r v a l ( min ) : 0
25 S u p p r e s s Empty User : No
26
27 Type | Method Mode
28 +
29 Network | None
30 Exec | None
31 System | None
32 Commands | None
33
34
35 ProCurve Switch 261048# show r a d i u s
36
37 S t a t u s and Counters G e n e r a l RADIUS I n f o r m a t i o n
38
39 Deadtime ( min ) : 0
40 Timeout ( s e c s ) : 5
41 R e t r a n s m i t Attempts : 3
42 G l o b a l E n c r y p t i o n Key :
43
44 Auth Acct
45 S e r v e r IP Addr Port Port E n c r y p t i o n Key
46
47 172.20.6.3 1812 1813
Supplicant
Apos a configurac
ao da autenticacao 802.1X no supplicant, esta pode ser
testada. Caso as credenciais introduzidas estejam corretas e se o utilizador
estiver autorizado a aceder `
a rede, no servidor RADIUS sera registada a
autenticac
ao com sucesso. Pode-se ver um exemplo de tal mensagem na
Listagem 5.8. Nesta mensagem e registado o nome do utilizador, o nome
e a porta do switch em que este se ligou, bem como o endereco MAC do
equipamento utilizado.
Listagem 5.8: Registo com sucesso de autenticacao no RADIUS

1 r a d i u s r a d i u s d [ 2 4 8 1 7 ] : ( 3 4 ) Login OK: [AD\\8010016/ < v i a Auth
Type = EAP>] ( from c l i e n t S w i t c h t e s t e p o r t 0 v i a TLS t u n n e l )
U t i l i z a d o r OK:
2 r a d i u s d [ 2 4 8 1 7 ] : ( 3 5 ) Login OK: [AD\\8010016/ < v i a AuthType = EAP
>] ( from c l i e n t S w i t c h t e s t e p o r t 1 c l i c8 1f 66b6dbc2 )
U t i l i z a d o r OK:
Endere
camento IP
Apos a autenticac
ao com sucesso, cada um cliente obtem um endereco IPv6.
A atribuic
ao de enderecos IPv6 e registada conforme se pode ver na Figura
5.9. Em particular, pode-se ver o DUID que identifica o cliente. Os ultimos
48 bits do DUID contem o endereco MAC da placa de rede do cliente. Tal
permite identificar o utilizador efetuando cruzamento de logs com os logs do
servidor RADIUS.
Figura 5.9: Registo de atribuicao de endereco IPv6
Resolu
cao de nomes
Foram efetuados testes de resolucao de equipamentos com endereco IPv6,
tanto servidores internos como externos. A Listagem 5.9 apresenta o re-
sultado de alguns dos testes de resolucao de nomes de servicos internos da
ESTG (moodle) e de servicos externos (Facebook).
Listagem 5.9: Teste de resolucao de nomes IPv6

1 n s l o o k u p moodle . e s t g . i p p . pt
2 S e r v e r : dns01 . i n t r a . e s t g . i p p . pt
3 Address : 2 0 0 1 : 6 9 0 : 2 3 c0 : 2 0 0 2 : : 3
4
6 Name : moodle . e s t g . i p p . pt
7 Addresses : 2 0 0 1 : 6 9 0 : 2 3 c0 : 2 0 0 1 : : 4
8 172.20.5.4
9
10 n s l o o k u p f a c e b o o k . com
11 S e r v e r : dns01 . i n t r a . e s t g . i p p . pt
12 Address : 2 0 0 1 : 6 9 0 : 2 3 c0 : 2 0 0 2 : : 3
13
15 Name : f a c e b o o k . com
16 A d d r e s s e s : 2 a03 : 2 8 8 0 : f 1 1 2 : 8 3 : f a c e : b00c : 0 : 2 5 de
17 31.13.71.36
Filtragem de tr
afego
Em todas as regras de firewall foi ativada a opcao de logging para que seja
possvel efetuar o registo de toda a atividade de rede, tal como se pode ver
na Figura 5.10 onde e possvel visualizar tanto trafego autorizado, como

trafego negado com origem nos clientes IPv6.
Figura 5.10: Logs da firewall Pfsense
O servidor de logs e o local onde todos os registos vistos anteriormente
sao armazenados e conservados durante um ano. A Listagem 5.10 apre-
senta um excerto deste registo de atividade. As linhas 1 e 2 desta listagem
retratam um processo de autenticacao 802.1X com sucesso, do utilizador
8010016, ligado ` a porta tres do switch Switch teste e com o endereco MAC
c8:1f:66:b6:db:c2. As linhas 3 e 4 registam o processo de DHCPv6 e a atri-
buicao do endereco IPv6 2001:690:23c0:2013:ed78:a5da:fbd:af35 ao cliente
com o DUID 00:01:00:01:1e:fe:d8:41:c8:1f:66:b6:db:c2. Pode-se constatar
que os u ltimos 48 bits do DUID correspondem ao endereco MAC do equi-
pamento em uso pelo utilizador 8010016. A linha 5 corresponde ao registo
de um acesso a uma p agina web (porta 80). Por u ltimo, a linha 6 retrata
uma tentativa de acesso a um servico na porta 8080. Esta tentativa foi blo-
queada porque n ao existe uma regra explicita de permissao na configuracao
da firewall. A informac ao registada nestes logs permite a identificacao dos
utilizador repons aveis por quaisquer acesso (ou tentativa) à Internet.
Listagem 5.10: Registo de atividade no Rsyslog

1 Nov 5 1 6 : 2 8 : 1 8 r a d i u s r a d i u s d [ 1 9 9 0 ] : ( 5 6 0 ) Login OK: [AD
\\8010016/ < v i a AuthType = EAP>] ( from c l i e n t S w i t c h t e s t e
p o r t 0 v i a TLS t u n n e l ) U t i l i z a d o r OK:
2 Nov 5 1 6 : 2 8 : 1 8 r a d i u s r a d i u s d [ 1 9 9 0 ] : ( 5 6 1 ) Login OK: [AD
\\8010016/ < v i a AuthType = EAP>] ( from c l i e n t S w i t c h t e s t e
p o r t 3 c l i c8 1f 66b6dbc2 ) U t i l i z a d o r OK:
3 Nov 5 1 6 : 2 6 : 3 5 1 7 2 . 2 0 . 6 . 2 5 3 dhcpd : A d v e r t i s e NA: S o l i c i t
message from f e 8 0 : : 9 d85 : c e f 2 : d39a : ba82 p o r t 5 4 6 , t r a n s a c t i o n
ID 0xFA11C000
4 Nov 5 1 6 : 2 6 : 3 5 1 7 2 . 2 0 . 6 . 2 5 3 dhcpd : Reply NA: a d d r e s s
2 0 0 1 : 6 9 0 : 2 3 c0 : 2 0 1 3 : ed78 : a5da : fbd : a f 3 5 t o c l i e n t with duid
0 0 : 0 1 : 0 0 : 0 1 : 1 e : f e : d8 : 4 1 : c8 : 1 f : 6 6 : b6 : db : c2 i a i d = 46669670
v a l i d f o r 7200 s e c o n d s
5 Nov 5 1 6 : 3 2 : 5 1 1 7 2 . 2 0 . 6 . 2 5 3 f i l t e r l o g :
1 5 4 , 1 6 7 7 7 2 1 6 , , 1 4 7 7 3 2 8 3 0 8 , em1 vlan650 , match , pass , in , 6 , 0 x00 , 0
x00000 , 6 4 ,UDP, 1 7 , 5 3 , 2 0 0 1 : 6 9 0 : 2 3 c0 : 2 0 1 3 : ed78 : a5da : fbd : a f 3 5
, 2 0 0 1 : 6 9 0 : 2 3 c0 : 2 0 0 2 : : 3 , 5 5 2 9 1 , 5 3 , 5 3
6 Nov 5 1 6 : 3 2 : 5 4 1 7 2 . 2 0 . 6 . 2 5 3 f i l t e r l o g : 7 , 1 6 7 7 7 2 1 6 , , 1 0 0 0 0 0 0 1 0 5 ,
em1 vlan650 , match , b l o c k , in , 6 , 0 x00 , 0 x00000 , 6 4 ,TCP
, 6 , 3 2 , 2 0 0 1 : 6 9 0 : 2 3 c0 : 2 0 1 3 : ed78 : a5da : fbd : a f 3 5 , 2 0 0 1 : 8 a0 : 2 1 0 4 : f f
: 2 1 3 : 1 3 : 1 4 6 : 1 3 8 , 4 9 4 7 6 , 8 0 8 0 , 0 , S , 5 9 7 0 7 8 7 9 , , 8 1 9 2 , , mss ; nop ; w s c a l e
; nop ; nop ; sackOK
Captulo 6
Conclus
ao
A atual rede da ESTG opera em IPv4 e tem suporte para autenticacao

de ligacoes à rede sem-fios eduroam. Ligacoes à rede por cabo nao sao
autenticadas e n ao h
a ligac
ao `
a Internet por IPv6. O objetivo proposto neste
projeto foi o da avaliac ao, por meio da implementacao de um prototipo, da
viabilidade de implementac ao de mecanismos de autenticacao para a rede
cablada (802.1X), em conjunto com a migracao da rede para IPv6. Foram
estudadas v arias soluc
oes que permitem efetuar o controlo de acesso à rede
nomeadamente a autenticac ao baseada em MAC address, em Kerberos, em
Captive Portal e em 802.1X. Dependendo do cenario de implementacao,
todas estas poder ao ser consideradas como opcoes validas, pese embora todas
com vantagens e desvantagens. A autenticacao baseada em MAC address
autentica um dispositivo utilizando o endereco fsico de origem das tramas
recebidas, podendo efetuar este tipo de autenticacao atraves do switch, ou
de forma centralizada utilizando um servidor RADIUS. Kerberos e um
protocolo de autenticac ao de rede, projetado para fornecer autenticacao para
aplicacoes cliente/servidor utilizando criptografia de chave privada. Uso de
Captive Portal consiste em forcar a apresentacao de uma pagina web aos
utilizadores quando estes se tentam ligar a uma rede p ublica, requerendo que
o utilizador faca algum tipo de operacao antes de obter acesso aos recursos
da rede. Por u ltimo, o 802.1X e mecanismo de controlo de acesso à rede,
baseado em portas, que permite verificar a legitimidade dos utilizadores que
pretendem aceder aos recursos de rede.
O IPv4 n ao sofreu mudancas significativas desde que foi publicado em
1981, tendo por isso v arias limitacoes. A versao 6 do IP foi desenvolvida
para superar as limitac oes do IPv4, introduzindo tambem funcionalidades
novas que visam melhorar a operacao da rede. Alguns destes melhoramentos
incluem-se a simplificac
ao do cabecalho do pacote IPv6, a auto-configuracao,
o multicast como parte da especificacao base do protocolo e o suporte para
mobilidade. O IPv6 tem diferencas significativas relativamente ao IPv4.
Uma vez que o protocolo IPv6 n ao e compatvel com IPv4, e necessaria a
59
60 Conclusao
implementac ao de mecanismos de transicao para a IPv6. Existem varios

mecanismos desenvolvidos especificamente para suportar esta transicao e
que permitem a coexistencia das duas versoes do IP. Mecanismos tais como
o Dual Stack, Tunneling e Translation.
A atual proposta de solucao permite dotar a rede da ESTG de auten-
ticac
ao para todos os acessos, independentemente do meio utilizado (cabo,
sem fios), e de suporte ao funcionamento simultaneo IPv4 e IPv6.
6.1 Resultados
A soluc
ao encontrada pode ser dividida em duas partes. Uma parte que
consiste na implementacao de autenticacao, autorizacao e criacao de uma
guest-vlan na rede cablada . A outra parte que consiste na configuracao
dos servicos associados ao IPv6, de que sao exemplo a configuracao de IP, o
roteamento, o servico de DNS e filtragem de trafego e o registo de atividade
na rede.
802.1X
A implementac ao de 802.1X permitiu dotar a rede da ESTG de mecanis-

mos de autenticac ao e autorizacao na rede cablada e requer um suplicant,
um authenticator e um servidor de autenticacao. Na solucao proposta, o
servidor de autenticac
ao tem uma AD como backend para autenticacao. Os
equipamentos tipo supplicant podem ser de varios tipos como PCs, impres-
soras, switchs ou routers. Na ESTG os sistemas operativos em uso sao o
Windows 10, o Fedora 24 e o MacOS ElCapitan. Foram efetuados testes
de configuracao nestes sistemas operativos que demonstraram a sua total
compatibilidade com o protocolo 802.1X.
Para os authenticators, equipamento de rede responsavel pela auten-
ticac
ao de um supplicant, existem em funcionamento na rede da ESTG varios
equipamentos de rede de diferentes marcas, tais como: HP, 3COM, Dell e
Cisco. Foram analisados os varios equipamentos e constatou-se que todos
suportam o referido protocolo. O servidor de autenticacao implementado foi
o FreeRadius que suporta os protocolos de autenticacao mais comuns, que
foi configurado com backend de autenticacao numa Active Directory 2012
R2.
Foi ainda implementada uma guest-vlan onde os utilizadores nao auten-
ticados sao colocados. No gateway desta VLAN, foi configurado um captive
portal que apresenta as instrucoes de configuracao a seguir pelos utilizado-
res para terem acesso ` a rede. Apos autenticacao na rede, os clientes sao
colocados na VLAN normal.
61 Conclusao
IPv6
A implementac ao de IPv6 na rede da ESTG implicou algumas alteracoes de
servicos existentes e a implementacao de novos. O servico de DNS foi recon-
figurado para aceitar e responder a querys IPv6, bem como foram inseridos
os registos do tipo AAAA referentes aos servicos internos implementados
em IPv6. Foi implementado o servico de DHCPv6 recorrendo à appliance
Pfsense, sendo utilizado o modo de configuracao stateful, obedecendo ao
plano de enderecamento definido para a ESTG. Os servicos de roteamento
e filtragem de trafego foram implementados recorrendo tambem à appliance
Pfsense seguindo as mesmas polticas de acesso implementadas e em funci-
onamento para IPv4.
Por u
ltimo foram tambem implementados mecanismos de registo de ati-
vidade ou logging que tem como funcao a recolha de dados de varios dispo-
sitivos e sua consolidacao num u
nico local onde possam ser monitorizados,
pesquisados e analisados.
6.2 Trabalho futuro

Futuras oportunidades de trabalho surgiram durante o desenvolvimento
deste projeto. A implementac ao do prototipo devera ser feita de forma
gradual em todos os laborat orios e na rede de servicos da ESTG. Todos os
testes necess
arios para a implementacao foram efetuados, tendo sidos testa-
dos todos os sistemas e equipamentos em uso na ESTG. A implementacao
devera por isso decorrer sem a existencia de problemas tecnicos.
Esta proposta de implementacao vai concentrar num ponto o registo
de atividade de toda a rede, incluindo os logs de acessos de utilizadores
e autenticac
oes. A an alise destes logs pode tornar-se complexa devido à
grande quantidade de utilizadores na rede e, por consequencia, a quantidade
de logs gerados. Por esse motivo seria interessante o estudo e implementacao
de ferramentas que permitam a analise e tratamento de logs.
O protocolo IPv6 tem novas funcionalidades que nao foram testadas
neste projeto. Uma destas funcionalidades e o suporte para mobilidade,
que permite manter o endereco IP quando se muda de rede, o que pode ser
interessante para varios equipamentos e servicos.
62 Conclusao
Bibliografia
[1] BGP Reports. http://bgp.potaroo.net/index-bgp.html. Accessed:

2016-09-08.
[2] Getting Started With pfSense Software. https://pfsense.org/

getting-started/. Accessed: 2016-09-25.
[3] RFC 791 - Internet Protocol. Technical report, Information Sciences

Institute, University of Southern California, sep 1981.
[4] How Does RADIUS Work? http://www.

cisco.com/c/en/us/support/docs/security-vpn/
remote-authentication-dial-user-service-radius/12433-32.
html, 2006. Accessed: 2016-09-25.
[5] Bernard Aboba, Henrik Levkowetz, Dan Simon, and Pasi Eronen.
Extensible authentication protocol (eap) key management framework.
2008.
[6] Ishtiaq Ahmed. IPv6 - Coexistence and Integration with Next Genera-
tion Networks. pages 114.
[7] Ana Ali. Comparison study between IPV4 & IPV6. International Jour-
nal of Computer Science Issues,, 9(3):314317, 2012.
[8] Y U I N G W Ang, N Ational T Sing, and H U A U Niversity. Exten-

sible Authentication Protocol (EAP) and IEEE 802.1x: Tutorial and
Empirical Experience. (December):2632, 2005.
[9] Olabenjo Babatunde and Omar Al-debagy. A Comparative Review

of Internet Protocol Version 4 (IPv4) and Internet Protocol Version
6 (IPv6). International Journal of Computer Trends and Tecnology,
13(1):1013, 2014.
[10] Marcelo Bagnulo, Philip Matthews, and Iljitsch van Beijnum. Stateful
nat64: Network address and protocol translation from ipv6 clients to
ipv4 servers. 2011.
63
64 Conclusao
[11] Marcelo Bagnulo, Philip Matthews, Andrew Sullivan, and Iljitsch van
Beijnum. Dns64: Dns extensions for network address translation from
ipv6 clients to ipv4 servers. 2011.
[12] How Can, I Implement User, Authentication Overview, Configuring

Authentication, and Authentication Configuration Example. Configu-
ring User Authentication. pages 136, 2011.
[13] Edgar D Cardenas. MAC SpoofingAn Introduction. (SANS Institute),

2003.
[14] Brian Carpenter and Keith Moore. Connection of ipv6 domains via
ipv4 clouds. Technical report, 2001.
[15] Cisco. Cisco LEAP - Cisco. http://www.cisco.com/c/en/us/

products/collateral/wireless/aironet-1200-series/prod{\_
}qas0900aecd801764f1.html, 2005. Accessed: 2016-10-06.
[16] Paul Congdon, Bernard Aboba, Andrew Smith, G Zorn, and J Roese.
Ieee 802.1 x remote authentication dial in user service (radius) usage
guidelines. Technical report, 2003.
[17] Steve Deering and Robert Hinden. Rfc 2460: Internet protocol, 1998.
[18] Jinesh Doshi, Rachid Chaoua, Saurabh Kumar, and Sahana Mallya. A
Comparative Study of IPv4 / IPv6 Co-existence Technologies. pages
113, 2012.
[19] Ralph Droms, Jim Bound, Bernie Volz, Ted Lemon, C Perkins, and
Mike Carney. Dynamic host configuration protocol for ipv6 (dhcpv6).
Technical report, 2003.
[20] Herny Elisa Erwin. The IEEE 802.1x Port-Based Network Access Con-
trol and Its Implementation. Technical Report Security 401, 2002.
[21] FreeRADIUS. FreeRADIUS - Survey Results. http://freeradius.

org/press/survey.html, 2015. Accessed: 2015-10-05.
[22] Vince Fuller, Tony Li, Jessica Yu, and Kannan Varadhan. Classless
inter-domain routing (cidr): an address assignment and aggregation
strategy. Technical report, 1993.
[23] Paul Funk and Simon Blake-Wilson. Extensible authentication protocol

tunneled transport layer security authenticated protocol version 0 (eap-
ttlsv0). 2008.
[24] RE Gilligan and Erik Nordmark. Transition mechanisms for IPv6 hosts
and routers. 1996.
65 Conclusao
[25] Jivika Govil, Jivesh Govil, Navkeerat Kaur, and Harkeerat Kaur. An
examination of IPv4 and IPv6 networks: constraints and various transi-
tion mechanisms. Conference Proceedings - IEEE SOUTHEASTCON,
pages 178185, 2008.
[26] Silvia Hagen. IPv6 Essentials, volume 159. 2006.
[27] Jun-ichiro Hagino and Kazu Yamamoto. An ipv6-to-ipv4 transport

relay translator. Technical report, 2001.
[28] Robert M Hinden and Stephen E Deering. Internet protocol version 6

(ipv6) addressing architecture. 2003.
[29] Kjell J Hole. Securing Wi-Fi Networks. 2005.
[30] Internet Systems Consortium. BIND Internet Systems Consortium.

https://www.isc.org/downloads/bind/, 2016. Accessed: 2016-10-
02.
[31] Cisco Ios and Learning Services. The ABCs of IP Version 6. page 76,
2008.
[32] David Johnson, Charles Perkins, and Jari Arkko. Mobility support in
ipv6. Technical report, 2004.
[33] San Jose. Interface and Hardware Component Configuration Guide ,

Cisco IOS Release.
[34] John Kohl and Clifford Neuman. The kerberos network authentication
service (v5). Technical report, 1993.
[35] John T Kohl. The use of Encryption in {Kerberos} for Network Authen-
tication. \ifnum\shortbib=1{CRYPTO}\else{Advances in Cryptology
{CRYPTO}}\fi89, 435:3543, 1990.
[36] Stephen Lawson. Update: Icann assigns its last ipv4 addresses. Com-
puterworld, 3, 2011.
[37] Litech Systems Design. TAYGA - NAT64 for Linux. http://www.

litech.org/tayga/. Accessed: 2016/11/02.
[38] Chris Lonvick. The bsd syslog protocol. 2001.
[39] Johan Loos and Rodney Caudle. Implementing IEEE 802.1x for Wired
Networks. SANS Reading Room, pages 143, 2014.
[40] Michael Mackay, Christopher Edwards, Martin Dunmore, Tim Chown,

and Graca Carvalho. A scenario-based review of IPv6 transition tools.
IEEE Internet Computing, 7(3):2735, 2003.
66 Conclusao
[41] L A N Man, Standards Committee, and Ieee Computer. Port-Based

Network Access Control. 2001.
[42] Microsoft. Active Directory. https://msdn.microsoft.com/en-us/

library/bb742424.aspx. Accessed: 2016-10-02.
[43] Microsoft. The Future Of Windows: Directory Services in Windows Ser-

ver. https://technet.microsoft.com/en-us/magazine/2006.11.
futureofwindows.aspx. Accessed: 2016-10-02.
[44] Microsoft. Active Directory Collection: Active Directory.

https://technet.microsoft.com/en-us/library/cc780036(WS.
10).aspx{\#}w2k3tr{\_}ad{\_}over{\_}qbjd, 2014. Accessed:
2016-10-02.
[45] S P Miller, B C Neuman, J I Schiller, and J H Saltzer. Kerberos

Authentication and Authorization System. In Project Athena Technical
Plan, pages 132, 1987.
[46] Cristian Perez Monte, Mara Ines Robles, Gustavo Mercado, Carlos
Taffernaberry, Marcela Orbiscay, Sebastian Tobar, and Raul Moralejo
y Santiago Perez. Implementation and Evaluation of Protocols Transla-
ting Methods for IPv4 to IPv6 Transition. Journal of Computer Science
& Technology (JCS&T), 12(2):6470, 2012.
[47] Edmundo Monteiro and Fernando Boavida. Engenharia de Redes In-

form
aticas. FCA, 2011.
[48] Thomas Narten and Jarrod Johnson. Definition of the uuid-based

dhcpv6 unique identifier (duid-uuid). 2011.
[49] B Clifford Neuman and Theodore Tso. Kerberos: An authentica-

tion service for computer networks. IEEE Communications magazine,
32(9):3338, 1994.
[50] Erik Nordmark. Stateless ip/icmp translation algorithm (siit). 2000.
[51] Erik Nordmark and Robert Gilligan. Basic transition mechanisms for
ipv6 hosts and routers. Technical report, 2005.
[52] Edgar Parenti, Eric Knipp, Neal Chen, Bart Saylor, and Sam Browne.
Configuring IPv6 with Cisco IOS. Syngress Publishing, 2002.
[53] Helder Pereira. L7 Classification and Policing in the pfSense Platform.

21st International Teletraffic Congress (ITC 21), 2009, Paris, France.,
2009.
[54] Jon Postel et al. Rfc 791: Internet protocol. 1981.

67 Conclusao
[55] Jon Postel and Joyce K Reynolds. Rfc 1700 assigned numbers. Network
Working Group, 1994.
[56] Yakov Rekhter, Bob Moskowitz, Daniel Karrenberg, Geert Jan

de Groot, and Eliot Lear. Address allocation for private internets.
Technical report, 1996.
[57] Rsyslog. rsyslog. http://www.rsyslog.com/, 2016. Accessed: 2016-

10-02.
[58] Mohd Khairil Sailan, Rosilah Hassan, and Ahmed Patel. A compara-
tive review of IPv4 and IPv6 for research test bed. Proceedings of the
2009 International Conference on Electrical Engineering and Informa-
tics, ICEEI 2009, 2(August):427433, 2009.
[59] Samba. SambaWiki. https://wiki.samba.org/index.php/Main{\_

}Page, 2016. Accessed: 2016-10-02.
[60] Zeroshell Net Services. Captive Portal for HotSpot authentication,

2016.
[61] Dan Simon, Bernard Aboba, and Ryan Hurst. The eap-tls authentica-
tion protocol. Technical report, 2008.
[62] Dorothy Stanley, Jesse Walker, and Bernard Aboba. Extensible authen-
tication protocol (eap) method requirements for wireless lans. Technical
report, 2005.
[63] D Thaler, L Zhang, and G Lebovitz. Iab thoughts on ipv6 network

address translation. Technical report, 2010.
[64] Susan Thomson, Christian Huitema, Vladimir Ksinant, and Mohsen

Souissi. Dns extensions to support ip version 6. Technical report, 2003.
[65] George Tsirtsis and Pyda Srisuresh. Network address translation-

protocol translation (nat-pt). Technical report, 2000.
[66] Last Updated, Building Architectures, and Solve Business Problems.

Wired 802 . 1X Deployment Guide About Cisco Validated Design (
CVD ) Program. Cisco, 2011.
[67] S Clement Virgeniya and V Palanisamy. Attacks on Ipv4 and Ipv6

Protocols and it s Performance Parameters. 4(8):24292434, 2013.
[68] Sean Wilkins. IPv6 Translation and Tunneling Technologies, 2013.
[69] Steve Willens, Allan C Rubens, Carl Rigney, and William Allen Simp-
son. Remote authentication dial in user service (radius). 2000.
68 Referencias
[70] Haidong Xia and Jose Brustoloni. Detecting and blocking unauthorized
access in Wi-Fi networks. . . . , Services, and Protocols; Performance
of Computer . . . , pages 795806, 2004.
Anexos
69
Ap
endice A
Configura
c
ao do tayga
Listagem A.1: Ficheiro de configuracao do tayga

1 tund e v i c e nat64
2 ipv4addr 1 9 2 . 1 6 8 . 2 5 5 . 1
3 p r e f i x 2 0 0 1 : 6 9 0 : 2 3 c0 : f f f f : : / 9 6
4 dynamicp o o l 1 9 2 . 1 6 8 . 2 5 5 . 0 / 2 4
5 datad i r / var / l i b / tayga / d e f a u l t
Listagem A.2: Script de inicializacao do tayga

1 tayga mktun
2 i p l i n k s e t nat64 up
3 i p addr add 1 7 2 . 2 0 . 1 0 0 . 3 0 dev nat64
4 i p addr add 2 0 0 1 : 6 9 0 : 2 3 c0 : 2 0 5 0 : : 1 dev nat64
5 i p r o u t e add 1 9 2 . 1 6 8 . 2 5 5 . 0 / 2 4 dev nat64
6 i p r o u t e add 2 0 0 1 : 6 9 0 : 2 3 c0 : f f f f : : / 9 6 dev nat64
7 echo 1 > / p r o c / s y s / n e t / i p v 4 / c o n f / a l l / f o r w a r d i n g
8 echo 1 > / p r o c / s y s / n e t / i p v 6 / c o n f / a l l / f o r w a r d i n g
9 i p t a b l e s F
10 i p t a b l e s t nat F
11 i p t a b l e s t nat A POSTROUTING o e t h 0 j MASQUERADE
12 i p t a b l e s A FORWARD i e t h 0 o nat64 m s t a t e s t a t e
RELATED, ESTABLISHED j ACCEPT
13 i p t a b l e s A FORWARD i nat64 o e t h 0 j ACCEPT
14 i p t a b l e s A FORWARD j LOG l o g l e v e l 3 l o g p r e f i x
FORWARDREJECT
15 s e r v i c e tayga s t a r t
71
72 Anexos
Ap
endice B
Configura
c
ao do
Authenticator
Configurac
ao dos switchs utilizados (HP Procurve).
Listagem B.1: Configuracao do switch HP Procurve

1 ProCurve Switch 261048# show runningc o n f i g
2
3 Running c o n f i g u r a t i o n :
4
5 ; J9088A C o n f i g u r a t i o n E d i t o r ; Created on r e l e a s e #R. 1 1 . 0 7
6
7 hostname ProCurve Switch 2610 48
8 no t e l n e t s e r v e r
9 i p d e f a u l t gateway 1 9 2 . 1 6 8 . 3 . 2 5 4
10 snmps e r v e r community p u b l i c U n r e s t r i c t e d
11 vlan 1
12 name DEFAULT VLAN
13 untagged 148,5052
14 i p a d d r e s s dhcpbootp
15 no untagged 49
16 exit
17 v l a n 601
18 name 19216830
19 ip address 192.168.3.70 255.255.255.0
20 t a g g e d 50
21 exit
22 v l a n 650
23 name LANIPV6
24 t a g g e d 50
25 exit
26 v l a n 649
27 name GuestVlan
28 untagged 49
29 t a g g e d 50
30 exit
73
74 Anexos
31 aaa a u t h e n t i c a t i o n port a c c e s s eapr a d i u s

32 r a d i u s s e r v e r h o s t 1 7 2 . 2 0 . 6 . 3 key
33 aaa port a c c e s s a u t h e n t i c a t o r 148
34 aaa port a c c e s s a u t h e n t i c a t o r 1 authv i d 650
35 aaa port a c c e s s a u t h e n t i c a t o r 1 unauthv i d 649
36 aaa port a c c e s s a u t h e n t i c a t o r 1 c l i e n t l i m i t 1
37 ...
38 ...
39 ...
40 aaa port a c c e s s a u t h e n t i c a t o r 48 authv i d 650
41 aaa port a c c e s s a u t h e n t i c a t o r 48 unauthv i d 649
42 aaa port a c c e s s a u t h e n t i c a t o r 48 c l i e n t l i m i t 1
43 aaa port a c c e s s a u t h e n t i c a t o r a c t i v e
44 aaa port a c c e s s 148
45 ip ssh
Ap
endice C
Configura
c
ao dos Clientes
C.1 Windows 10
1. Clique em Iniciar e escreva services.
2. Aceda a services.msc.
3. Ir
a abrir uma janela como a que pode ver na figura C.1.
Figura C.1: Servicos
4. Procure o servico Wired Auto Confige inicie-o.
5. Aceda ao Network and Sharing Center(figura C.2) e escolha a opcao

Change adapter settings.
75
76 Anexos
Figura C.2: Network Center
6. Editar as propriedades da placa de rede e selecionar o separador Authen-

tication.
7. No separador Authenticationselecione as opcoes conforme a figura

C.3, selecione a opcao de autenticacao PEAP e clique em settings.
77 Anexos
Figura C.3: Propriedades da placa de rede
8. Selecionar a opc
ao de autenticacao EAP-MSCHAP v2 e clicar em con-
figurar (figura C.4)
78 Anexos
Figura C.4: Propriedades EAP
9. Retirar a selec
ao da opcao Automatic use my windows logon name...(figura
C.5).
79 Anexos
Figura C.5: Propriedades do EAP MSCHAPv2
10. Clicar em OK ate chegar `

a figura C.3.
11. Clicar na opc

ao Adicional Settings.
12. Selecionar a opc

ao Specify authentication modee escolher a opcao
User authentication(figura C.6).
80 Anexos
Figura C.6: Propriedades avancadas da autenticacao
13. Clicar em OK.
14. Dever
a aparecer uma janela a pedir o seu nome de utilizador e pas-
sword (figura C.7). Introduza as suas credenciais e clique em OK.
81 Anexos
Figura C.7: Janela de autenticacao 802.1X
15. Dever
a estar ligado `
a rede.
C.2 Fedora 24
1. Aceder ao Network Manager
2. Selecionar a rede cablada.
3. Clicar em propriedades.
Figura C.8: Network Manager
4. Aceder ao tab security.
5. Ativar a autenticac
ao 802.1X.
82 Anexos
6. Selecionar o metodo de autenticacao PEAP.
7. Introduzir username e password.
Figura C.9: Janela de configuracao 802.1X
8. Aplicar as configuracoes.
C.3 MacOs
1. Quando se liga `
a rede vai aparecer uma janela a pedir as suas creden-
ciais como se pode ver na figura C.10
Figura C.10: Pedido de credenciais

83 Anexos
2. Introduza as suas credenciais e clique em OK (figura C.11).
Figura C.11: Introduzir credenciais
3. Caso seja a primeira vez que acede à rede vai aparecer uma janela,
como a que se pode visualizar na figura C.12, com informacoes sobre
o certificado. Clique em continuar.
Figura C.12: Apresentacao do certificado
4. Para aceitar o certificado sera pedido as suas credenciais de login no

seu computador (figura C.13). Insira-as e lique em Update Settings.
84 Anexos
Figura C.13: Aceitacao do certificado
5. Pode verificar o estado da ligacao nas preferencias de rede. Na Figura

C.14 pode-se visualizar o estado da ligacao. Na opcao 802.1X pode-se
ver que a ligac
ao foi estabelecida e qual o protocolo de ligacao.
Figura C.14: Propriedades da rede

Ap
endice D
Configurac
ao do servidor de
autentica
c
ao
Listagem D.1: Ficheiro de configuracao radiusd.conf

1
2 [ r o o t @ r a d i u s ]# vim / e t c / raddb / r a d i u s d . c o n f
3
4 p r e f i x = / usr
5 e x e c p r e f i x = / usr
6 sysconfdir = / etc
7 l o c a l s t a t e d i r = / var
8 s b i n d i r = / usr / sbin
9 l o g d i r = $ { l o c a l s t a t e d i r }/ l o g / r a d i u s
10 r a d d b d i r = $ { s y s c o n f d i r }/ raddb
11 r a d a c c t d i r = $ { l o g d i r }/ r a d a c c t
12
13 name = r a d i u s d
14
15 c o n f d i r = ${ raddbdir }
16 m o d c o n f d i r = $ { c o n f d i r }/modsc o n f i g
17 c e r t d i r = $ { c o n f d i r }/ c e r t s
18 cadir = $ { c o n f d i r }/ c e r t s
19 r u n d i r = $ { l o c a l s t a t e d i r }/ run / $ {name}
20
21 d b d i r = $ { l o c a l s t a t e d i r }/ l i b / r a d i u s d
22
23 l i b d i r = / usr / lib64 / f r e e r a d i u s
24 p i d f i l e = $ { r u n d i r }/ $ {name } . p i d
25 m a x r e q u e s t t i m e = 30
26 cleanup delay = 5
27 m a x r e q u e s t s = 1024
28 h o s t n a m e l o o k u p s = no
29
30 log {
31 destination = syslog
32 c o l o u r i s e = yes
33 f i l e = $ { l o g d i r }/ r a d i u s . l o g
85
86 Anexos
34 s y s l o g f a c i l i t y = daemon
35 s t r i p p e d n a m e s = no
36 auth = y e s
37 auth badpass = yes
38 auth goodpass = yes
39 msg goodpass = U t i l i z a d o r OK:
40 msg badpass = NOK:
41 m s g d en i e d = You a r e a l r e a d y l o g g e d i n a c c e s s d e n i e d
42 }
43 c h e c k r a d = $ { s b i n d i r }/ c h e c k r a d
44 security {
45 user = radiusd
46 group = r a d i u s d
47 a l l o w c o r e d u m p s = no
48 m a x a t t r i b u t e s = 200
49 reject delay = 1
50 s t a t u s s e r v e r = yes
51 }
52
53 proxy requests = yes
54 $INCLUDE proxy . c o n f
55 $INCLUDE c l i e n t s . c o n f
56
57 thread pool {
58 start servers = 5
59 m a x s e r v e r s = 32
60 min spare servers = 3
61 m a x s p a r e s e r v e r s = 10
62 max requests per server = 0
63 a u t o l i m i t a c c t = no
64 }
65
66 modules {
67 $INCLUDE modse n a b l e d /
68 }
69 policy {
70 $INCLUDE p o l i c y . d/
71 }
72 $INCLUDE s i t e s e n a b l e d /
Listagem D.2: Ficheiro de configuracao ldap.conf

1 [ r o o t @ r a d i u s ]# vim / e t c / raddb /modsa v a i l a b l e / l d a p
2
3 ldap {
4 s e r v e r = dc . ad . e s t g . i p p . pt
5 p o r t = 636
6 i d e n t i t y = cn=A d m i n i s t r a t o r , cn=Users , dc=ad , dc=e s t g , dc=ipp , dc=pt

7 password =
8 b a s e d n = cn=Users , dc=ad , dc=e s t g , dc=ipp , dc=pt
9 update {
10 c o n t r o l :NTPassword :=
sambaNTPassword
87 Anexos
11 c o n t r o l :LMPassword :=
sambaLMPassword
12 }
13 user {
14 b a s e d n = $ { . . b a s e d n }
15 f i l t e r = ( u i d=%{%{S t r i p p e d UserName}:%{User
Name} } )
16 }
17 group {
18 b a s e d n = $ { . . b a s e d n }
19 f i l t e r = ( o b j e c t C l a s s=posixGroup )
20 m e m b e r s h i p a t t r i b u t e = memberOf
21 }
22 profile {
23 }
24 client {
25 b a s e d n = $ { . . b a s e d n }
26 f i l t e r = ( o b j e c t C l a s s=f r C l i e n t )
27 attribute {
28 identifier =
radiusClientIdentifier
29 secret =
radiusClientSecret
30 }
31 }
32 accounting {
33 r e f e r e n c e = %{ t o l o w e r : type .%{ AcctS t a t u s Type
}}
34 type {
35 start {
36 update {
37 d e s c r i p t i o n := O n l i n e
a t %S
38 }
39 }
40 i n t e r i m update {
41 update {
42 d e s c r i p t i o n := L a s t
s e e n a t %S
43 }
44 }
45 stop {
46 update {
47 d e s c r i p t i o n := O f f l i n e
a t %S
48 }
49 }
50 }
51 }
52 post auth {
53 update {
54 d e s c r i p t i o n := A u t h e n t i c a t e d a t %S
55 }
56 }
88 Anexos
57 options {
58 c h a s e r e f e r r a l s = yes
59 rebind = yes
60 rebind = yes
61 t i m e o u t = 10
62 timelimit = 3
63 net timeout = 1
64 i d l e = 60
65 probes = 3
66 interval = 3
67 l d a p d e b u g = 0 x0028
68 }
69 tls {
70 require cert = allow
71 }
72 pool {
73 start = 5
74 min = 4
75 max = $ { t h r e a d [ p o o l ] . m a x s e r v e r s }
76 spare = 3
77 uses = 0
78 lifetime = 0
79 i d l e t i m e o u t = 60
80 }
81 }
Listagem D.3: Ficheiro de configuracao sites-enabled/default mschap

1 [ r o o t @ r a d i u s ]# vim / e t c / raddb /modsa v a i l a b l e / n t l m a u t h
2
3 mschap {
4 use mppe = no
5 r e q u i r e e n c r y p t i o n = yes
6 r e q u i r e s t r o n g = yes
7 with ntdomain hack = yes
8 n t l m a u t h = / u s r / b i n / n t l m a u t h r e q u e s t ntkey
username=%{%{S t r i p p e d UserName}:%{%{UserName}:
None}} c h a l l e n g e=%{%{mschap : C h a l l e n g e }: 00} nt
r e s p o n s e=%{%{mschap :NTResponse }: 00}
9 passchange {
10 }
11 }
Listagem D.4: Ficheiro de configuracao do sites-enabled/default

1
2 [ r o o t @ r a d i u s ]# vim / e t c / raddb / s i t e s e n a b l e d / d e f a u l t
3
4 server default {
5 listen {
6 type = auth
7 ipaddr =
8 port = 0
9 limit {
89 Anexos
10 m a x c o n n e c t i o n s = 16
11 lifetime = 0
12 i d l e t i m e o u t = 30
13 }
14 }
15 listen {
16 ipaddr =
17 port = 0
18 type = a c c t
19 limit {
20 }
21 }
22 listen {
23 type = auth
24 ipv6addr = : : # any . : : 1 == l o c a l h o s t
25 port = 0
26 limit {
28 lifetime = 0
29 i d l e t i m e o u t = 30
30 }
31 }
32 listen {
33 ipv6addr = : :
34 port = 0
35 type = a c c t
36 limit {
37 }
38 }
39 authorize {
40 filter username
41 preprocess
42 chap
43 mschap
44 digest
45 ntdomain
46 eap {
47 ok = r e t u r n
48 }
49 files
50 s q l
51 l d a p
52 expiration
53 logintime
54 pap
55 }
56 authenticate {
57 AuthType PAP {
58 pap
59 }
60 AuthType CHAP {
61 chap
62 }
63 AuthType MSCHAP {
90 Anexos
64 mschap
65 }
66 digest
67 AuthType LDAP {
68 ldap
69 }
70 eap
71 }
72 preacct {
73 preprocess
74 acct unique
75 ntdomain
76 files
77 }
78 accounting {
79 detail
80 unix
81 s q l
82 exec
83 a t t r f i l t e r . accounting response
84 }
85 session {
86 }
87 post auth {
88 s q l
89 exec
90 remove reply message if eap
91 PostAuthType REJECT {
92 s q l
93 attr filter . access reject
94 eap
95 remove reply message if eap
96 }
97 }
98 preproxy {
99 }
100 post proxy {
101 eap
102 }
103 }
Listagem D.5: Ficheiro de configuracao sites-enabled/inner-tunnel

1 [ r o o t @ r a d i u s ]# vim / e t c / raddb / s i t e s e n a b l e d / i n n e r t u n n e l
2 s e r v e r i n n e r t u n n e l {
3 listen {
4 ipaddr = 1 2 7 . 0 . 0 . 1
5 p o r t = 18120
6 type = auth
7 }
8 authorize {
9 chap
10 mschap
11 ntdomain
91 Anexos
12 update c o n t r o l {
13 ProxyToRealm := LOCAL
14 }
15 eap {
16 ok = r e t u r n
17 }
18 files
19 s q l
20 l d a p
21 expiration
22 logintime
23 pap
24 }
25 authenticate {
26 AuthType PAP {
27 pap
28 }
29 AuthType CHAP {
30 chap
31 }
32 AuthType MSCHAP {
33 mschap
34 }
35 AuthType LDAP {
36 ldap
37 }
38 eap
39 }
40 session {
41 radutmp
42 }
43 post auth {
44 s q l
45 PostAuthType REJECT {
46 s q l
47 attr filter . access reject
48 }
49 }
50 preproxy {
51 }
52 post proxy {
53 eap
54 }
55 } # i n n e r t u n n e l s e r v e r b l o c k
Listagem D.6: Ficheiro de configuracao clients.conf

1 [ r o o t @ r a d i u s ]# vim / e t c / raddb / c l i e n t s . c o n f
2
3 client localhost {
4 ipaddr = 1 2 7 . 0 . 0 . 1
5 proto =
6 secret = testing123
7 r e q u i r e m e s s a g e a u t h e n t i c a t o r = no
92 Anexos
8 nas type = other # l o c a l h o s t isn t

u s u a l l y a NAS . . .
9 limit {
11 lifetime = 0
12 i d l e t i m e o u t = 30
13 }
14 }
15 client localhost ipv6 {
16 ipv6addr = ::1
17 secret = testing123
18 }
19 client Switch teste {
20 ipaddr = 192.168.3.70
21 secret =
22 }
Ap
endice E
Captive Portal
Figura E.1: Captive Portal com instrucoes de configuracao
93
94 Anexos
Ap
endice F
Configura
c
ao da pfsense
F.1 DHCP
Figura F.1: Configuracao DHCPv6 na pfsense
F.2 Regras de firewall
Figura F.2: Aliases na pfsense
95
96 Anexos
Figura F.3: Regras de firewall na pfsense

Ap
endice G
Plano de Endere
camento
IPv6
97
98 Anexos
Tabela G.1: Plano de enderecamento IPv6

Enderecamento IPV6 Enderecamento IPV4 Rede
2001:690:23c0:2000::/64 Reservado SP
2001:690:23c0:2001::/64 172.20.5.0 DMZ
2001:690:23c0:2002::/64 172.20.6.0 DMZ-Internal
2001:690:23c0:2003::/64 172.20.10.0 SRV-LAB
2001:690:23c0:2010::/64 172.20.100.0 LAN
2001:690:23c0:2011::/64 172.20.101.0 LAB P4
2001:690:23c0:2012::/64 172.20.102.0 LAB 1.5
2001:690:23c0:2013::/64 172.20.103.0 LAB 0.1
2001:690:23c0:2014::/64 172.20.104.0 LAB P6 (desativado)
2001:690:23c0:2015::/64 172.20.105.0 LAB 0.3
2001:690:23c0:2016::/64 172.20.106.0 Projecao
2001:690:23c0:2017::/64 172.20.107.0 LAB P7
2001:690:23c0:2018::/64 172.20.107.0 LAB P8
2001:690:23c0:2019::/64 172.20.107.0 LAB P9
2001:690:23c0:2020::/64 172.20.107.0 LAB P10
2001:690:23c0:2021::/64 172.20.108.0 LAB P11
2001:690:23c0:2030::/64 172.20.109.0 CIICESI

Jfonseca 2016 PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Jfonseca 2016 PDF

Enviado por

Direitos autorais:

Formatos disponíveis

E S C O L A S U P E R I O R D E T E C N O L O G I A E G E S T O

Implementao de autenticao 802.1.x e IPv6 na rede

O R I E N T A D O R ( E S ) Professor Doutor Antnio Alberto Santos Pinto

Este trabalho no inclui as crticas e sugestes feitas pelo Jri

Jorge Goncalo Monteiro da Fonseca

Orientador: Antonio Alberto Santos Pinto

Agradeco a todos os que me apoiaram neste percurso, dando-me forca e

Ao meu orientador, Professor Doutor Antonio Alberto dos Santos Pinto,

A` minha esposa Amelia, pela sua compreensao, apoio e incentivo. Aos

A atual rede da ESTG opera em IPv4 e so tem suporte para autenticacao

2 Controlo de acesso ` a rede 5

4.1 Diagrama atual da rede ESTG . . . . . . . . . . . . . . . . . 33

5.1 Esquema funcional do ambiente de testes . . . . . . . . . . . 44

C.9 Janela de configuracao 802.1X . . . . . . . . . . . . . . . . . . 82

E.1 Captive Portal com instrucoes de configuracao . . . . . . . . 93

2.1 Metodos de autenticac

3.1 Classes de enderecamento IPv4 . . . . . . . . . . . . . . . . . 20

4.1 VLANs em uso . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.1 Esquema de enderecamento IPv6 . . . . . . . . . . . . . . . . 49

G.1 Plano de enderecamento IPv6 . . . . . . . . . . . . . . . . . . 98

DoS: Denial of Service

TOS: Type of Service

IAB: Internet Architecture Board

No mundo tecnol ogico em que vivemos, os sistemas informaticos e as redes

gum tipo de controlo de acesso. Os computadores da instituicao ao servico

1.1 Objetivos do trabalho

1.2 Resultados relevantes

1. Autentica cao: Os utilizadores para terem acesso `a rede da ESTG

3. Guest-Vlan: Dever a existir uma Guest-Vlan com redirecionamento

5. Roteamento: O tr afego com destino a redes IPv4 e IPv6 devera ser

7. Filtragem de tr afego: Deverao estar definidas um conjunto de re-

8. Registo de atividade: A atividade dos utilizadores na rede devera

1.3 Estrutura do relat

Numa era de expans ao tecnol ogica como a que vivemos, os computadores e

HUB NAS Servidor

Figura 2.1: Autenticacao com RADIUS

dos equipamentos a utilizar, da complexidade de configuracao, etc, estes

1. O utilizador inicia autenticacao Point-to-Point Protocol (PPP) com o

2. O NAS solicita o nome de utilizador e senha (se se utilizar Password

3. O utilizador fornece a informacao solicitada pelo NAS.

4. O cliente RADIUS (re)envia a informacao do utilizador para o servidor

Figura 2.2: Autenticacao por endereco MAC

5. O servidor RADIUS responde com aceitacao, rejeicao ou com novo

6. O cliente RADIUS age de acordo com a resposta.

Atualmente, a utilizacao de servidores RADIUS surge muito frequente-

Figura 2.3: Autenticacao com Kerberos

Figura 2.4: Estrutura de mensagem do Kerberos

cliente e a restante informac

2.4 Captive Portal

Figura 2.5: Exemplo de autenticacao por Captive Portal

Figura 2.6: Esquema funcional 802.1x

Os Captive Portal tambem podem ser implementados num router, o de-

Algumas da implementac oes dos Captive Portal obrigam somente a que os

Figura 2.7: Componentes do 802.1x

Supplicant Servidor de Autenticao

Authentication Protocol (EAP).

EAP-MD5 - Utiliza um hash MD5, obtido a partir do nome de uti-

LEAP Metodo desenvolvido pela Cisco systems. Utiliza uma versao

EAP-TLS Utilizado em sistemas de seguranca baseados em certi-

EAP-TTLS - E uma extensao do EAP-TLS que requer somente cer-

PEAP suporta One-Time Password (OTP), Domnios Windows ou

Tabela 2.1: Metodos de autenticacao EAP

PEAP tem duas fases de autenticacao. Na fase 1 e efetuada a auten-