Escolar Documentos
Profissional Documentos
Cultura Documentos
Catalao - 2010
Rafael de Sales y Ulhoa
Catalao - 2010
S. Ulhoa, Rafael
Numero de paginas: 45
Professor 1
Professor 2
RESUMO
Ulhoa, R. S. Implementacao de 802.1X e RADIUS Integrado ao Active Di-
rectory e Network Access Protection no CAC/UFG. Curso de Ciencia da Com-
putacao, Campus Catalao, UFG, Catalao, Brasil, 2010, 45p.
O uso de polticas de acesso e seguranca numa rede torna possvel aos administradores
regulamentar o uso da infraestrutura e minimizar brechas de segurancas em dispostivos
de usuarios. Tais polticas podem ser implementadas dentro de um rede fazendo uso de
padroes e tecnologias como o IEEE 802.1X, RADIUS e Network Access Protection que
visam tambem contabilizar das acoes dos clientes alem de isolar dispostivos vulneraveis
em subredes. Este documento apresenta um estudo, projeto e processo de implementacao
das tecnologias citadas para a rede do campus Catalao da Universidade Federal de Goias.
1 Consideracoes Iniciais 1
2 Estado da Arte 2
2.1 Redes de Computadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.2 Seguranca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2.1 Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2.2 Infraestrutura de Rede . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2.3 Cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Criptografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3.1 Message-Digest Algorithm 5 . . . . . . . . . . . . . . . . . . . . . . 6
2.3.2 Certificados Digitais . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.3 Transport Layer Security . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.4 Protocolos para o Acesso Sem Fio . . . . . . . . . . . . . . . . . . . 6
2.4 Autenticacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4.1 Challenge-Handshake Authentication Protocol . . . . . . . . . . . . 7
2.4.2 Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4.3 EAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.5 Network Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.5.1 IEEE 802.1X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.6 Servidores de Autenticacao . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.6.1 Protocolo RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.6.2 Network Access Protection . . . . . . . . . . . . . . . . . . . . . . . 20
2.6.3 Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.7 Virtual LAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.8 Resumo do Captulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3 Ambiente de Implementacao 24
3.1 Estrutura Fsica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.1.1 Equipamentos de Rede . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.1.2 Sistemas Operacionais . . . . . . . . . . . . . . . . . . . . . . . . . 27
i
3.2 Servicos de Rede . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3 Problemas de Seguranca . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.4 Resumo do Captulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4 Implementacao 31
4.1 Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2 Implementacao dos Servidores . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.3 Configuracao dos Servidores . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.4 Autenticadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.5 Suplicantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.6 Resumo do Captulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5 Testes 38
5.1 Teste de Carga . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.2 Metricas de Avaliacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.3 Recursos dos Servidores . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.4 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6 Conclusoes Finais 41
6.1 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Bibliografias 43
ii
Lista de Figuras
iii
5.1 Grafico apresentando a variacao de processamento durante a execucao dos
testes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
iv
Lista de Tabelas
v
Captulo 1
Consideracoes Iniciais
1
Captulo 2
Estado da Arte
2
A necessidade de compartilhamento de recursos, sejam eles fsicos ou logicos, ou seja,
tornar todos os programas, equipamentos e dados ao alcance de todas os dispositivos
na rede, independente da localizacao fsica do recurso ou usuario;
Em decorrencia das aplicacoes e facilidades providas por uma rede, surgiu um novo
problema, como assegurar que o acessos aos servicos de rede estao sendo realizados por
usuarios autorizados.
2.2 Seguranca
Dentro de um modelo simplicado de comunicacao cliente/servidor, conforme apre-
sentado na figura 2.1, e possvel identificar tres pontos diferentes de vulnerabilidades; o
servidor, a infraestrutura de conexao e o cliente (usuario e seu dispositivo). Cada elemento
exige consideracoes diferentes para prover um ambiente seguro e confiavel.
2.2.1 Servidor
Os servicos executados nos servidores sao sujeitos a ocorrencia de brechas de seguranca
pelas quais um invasor podera usufruir-las de forma a comprometer o servidor. Os resul-
tados sao servicos de rede inconfiaveis ou ate mesmo inoperantes, alem da possibilidade
de informacoes sigilosas serem capturadas e usadas indevidamente pelo invasor. Como
solucao, servidores frequentemente fazem uso de tecnicas de autenticacao para regulamen-
tar as permissoes de cada usuario e registrar suas atividades.
3
2.2.2 Infraestrutura de Rede
A infraestrutura de uma rede possui dois criterios que merecem ser observados; a confi-
dencialidade dos dados sendo transmitidos e controle de acesso a rede [Zapater e Suzuki, 2005].
Por fornecer um ambiente de interconexao entre variados tipos de dispositivos aloca-
dos dentro de uma organizacao, redes tambem sao vulneraveis a usuarios maliciosos. De
acordo com a tecnologia de propagacao do meio, pacotes transmitidos entre clientes e ser-
vidores podem ser interceptados, como demonstrado na figura 2.2. Um solucao para este
problema e o uso de uma tecnica de criptografia para tornar as informacoes transmitidas
irreconhecveis para quem desconhece a tecnica e a chave utilizada [Burnett e Paine, 2002].
2.2.3 Cliente
Em um dispositivo cliente seja ele um computador, coletor de dados ou qualquer outro
dispositivo que esteja com a seguranca na comutacao de dados comprometida, credenciais
podem ser interceptadas antes mesmo de serem criptografadas e transmitidas pela rede. A
existencia de um keylogger, isto e, programa que registra todas as teclas digitadas, pode
ser o suficiente para que credenciais sejam capturadas e utilizadas indevidamente em
nome do seu dono autentico. Programas maliciosos como keyloggers sao frequentemente
propagadas via e-mail, unidades de armazenamento externas e pela rede local se aprovei-
tando de vulnerabilidades existente no sistema operacional executado no dispositivo do
4
cliente. A figura 2.3 exibe um cenario cujo dispositivo cliente se encontra comprometido
[Ulbrich e Valle, 2009].
2.3 Criptografia
Originado das palavras gregas kryptos (escondido) e graphein (escrita), criptografia e
amplamente utilizada em ambientes informatizados para que informacoes sigilosas sejam
lidas somente pelas pessoas autorizadas atraves de uma chave. O procedimento comum
entre as tecnicas existentes consiste em aplicar um conjunto de operacoes (algoritmo)
sobre a informacao que se deseja tornar particular, em conjunto com uma chave qual-
quer, gerando assim uma sequencia de sada. Para descriptografar se aplica um segundo
algoritmo, tambem trabalhando com uma chave (nao necessariamente a mesma) sobre
5
a sequencia gerada anteriormente. Caso uma chave errada seja utilizada, a informacao
resultante sera diferente da original.
Algumas tecnicas e protocolos de criptografia utilizadas pelas tecnologias abordadas
neste projeto sao apresentadas a seguir.
6
criptografia de forma a impedir a interceptacao de dados e o uso da rede por usuarios nao
autorizados.
A primeira tecnica padronizada foi o Wired Equivalent Privacy (WEP) com a promessa
de conceder confidencialidade de dados equivalente a de uma rede cabeada. Porem, com o
surgimento de tecnicas de criptoanalise capazes de descobrirem a sua chave em um curto
prazo de tempo, o WEP se tornou obsoleto [Borisov, Goldberg e Wagner, 2001].
A Wi-Fi Protected Access (WPA) e seu aprimoramento, WPA2, sao as atuais solucoes
padronizadas existentes para redes sem fio baseadas em algoritmos com seguranca mate-
maticamente provadas [Jonsson, 2002]. Tanto o WEP como o WPA e WPA2 sao baseados
na existencia de uma chave comum e compartilhada entre os usuarios e o AP.
2.4 Autenticacao
Como dito anteriormente, servidores fazem uso de autenticacao para gerenciar o acesso
de usuarios. Aliados ao uso de criptografia, as tecnias de autenticacao descritas a seguir
sao utilizadas pelo projeto.
7
2.4.2 Kerberos
O protocolo Kerberos foi desenvolvido para conceder uma mecanismo de autenticacao
dentro de redes desprotegidas, onde pacotes podem ser lidos, modificados ou inseridos
sem controle. O protocolo na versao 5 inicializa a sua operacao quando um cliente trans-
mite uma requisicao ao servidor de autenticacao solicitando suas credenciais, as quais
sao transmitidas criptografadas com a chave do cliente, por exemplo, sua senha. As
credenciais fornecidas pelo servidor contem um ticket e uma chave temporaria para uso
durante o perodo. O ticket por sua vez contem a identidade do cliente, uma copia da
chave temporaria, alem da indicacao do tempo de vida do ticket e outras informacoes de
identificacao como, por exemplo, o endereco do cliente.
Apos receber a mensagem do servidor, o cliente transmite de volta o ticket criptogra-
fado utilizando a chave temporaria para a validacao de sua sessao. Durante seu tempo de
vida, o ticket podera ser transmitido pelo cliente a todos os servicos de rede integrados
ao servidor como forma de identificacao. Cabe aos servicos consultarem o servidor para
confirmar a validade do ticket [Neuman et al., 2005].
2.4.3 EAP
Buscando unificar as diferentes tecnicas de criptografia dentro de um protocolo de co-
municacao unico, independente da aplicacao, o Extensible Authentication Protocol (EAP)
foi elaborado sobre a tutela da Internet Engineering Task Force (IETF) com apoio de
empresas como a Microsoft Corporation e Sun Microsystems (atual subsidiaria da Oracle
Corporation). O EAP prove uma arquitetura de autenticacao que trafega diretamente
sobre a camada de enlace, sem requerer o uso do Internet Protocol (IP). Por esta carac-
terstica o protocolo EAP e adotado por tecnologias de NAC como o IEEE 802.1X a ser
discutido em detalhes na secao 2.5.1 [Adoba et al., 2004].
A estrutura dos pacotes do protocolo EAP e dividida em quatro campos como apre-
sentado na figura 2.4 e descritos a seguir:
8
Codigo: Indica o formato do pacote EAP sendo transmitido dentro de um campo
contendo 1 octeto de bits. O seu valor pode ser, em decimal, um dos seguintes:
Dados: Contem zero ou mais octetos, de acordo com formato determinado no campo
codigo. Em pacotes Resquest e Response, este campo contem a identificacao de
uma tecnica de autenticacao (em 2 octetos) sucedido por seu(s) valor(es) associ-
ado(s). Pacotes Success e Failure nao utilizam este campo.
b) Tecnicas de Criptografia
9
Nome Estrutura e Descricao
MD5-Challenge Com ID 4, indica o uso do algoritmo MD5 de cripto-
grafia. Quando enviado atraves de um pacote Request,
contem um conjunto de dados denominados Challenge
que devera ser utilizado pelo algoritmo MD5 para crip-
tografar e enviar a senha do usuario.
EAP com TLS EAP-TLS, de ID 13, e baseado na tecnica de cripto-
grafia TLS. Porem, para a sua execucao e necessario
que tanto o cliente quando o autenticador possuam
um certificado proprio, cujas chaves publicas devem
ser armazenadas localmente em ambos dispositivos
[Aboba e Simon, 1999].
Lightweight EAP Possuindo ID 17, o LEAP e uma tecnica proprietaria de-
(LEAP) senvolvida pela empresa Cisco Systems, projetada para
o uso em redes sem-fio. Ela prove geracao automatica de
chaves WEP para criptografar a transmissao de dado. O
LEAP e reconhecido como vulneravel por ser susceptvel
a ataques por dicionario ao expor as senhas, em seu for-
mato criptografado, durante o processo de autenticacao.
EAP com Tunneled De ID 21, EAP-TTLS estabelece uma conexao segura
TLS (EAP-TTLS) utilizando TLS para em seguida utilizar uma segunda
tecnica qualquer, independente do protocolo EAP. O
EAP-TTLS exige que o autenticador possua um certifi-
cado e que o cliente tenha a chave publica armazenada
localmente. Nao ha a necessidade de um certificado para
o cliente [Funk e Blake-Wilson, 2008].
Protected EAP Identificado pelo ID 25, o PEAP opera de forma seme-
(PEAP) lhante ao EAP-TTLS, porem, ao contrario do EAP-TLS
e EAP-TTLS, o estabelecimento da conexao segura TLS
se inicia por parte do autenticador descartando a ne-
cessidade de armazenamento de certificados no cliente
[Palekar et al., 2004].
10
c) Modo de Operacao
11
servidor e oculta aos suplicantes. Na figura 2.5 e apresentada, dentro do modelo basico
cliente/servidor, a area de atuacao direta do padrao dentro de uma rede.
Figura 2.5: Modelo basico de uma rede demonstrando a area de atuacao direta e as tres
entidades definidas pelo padrao 802.1X.
Como forma de individualizar o funcionamento do IEEE 802.1X, cada porta das in-
terfaces de rede dos equipamentos e associada a uma entidade logica denominada Port
Access Entity (PAE). Os PAEs sao capazes de suportar as funcionalidades tanto de au-
tenticadores como de suplicantes.
Operando como suplicante a PAE e responsavel por fornecer informacoes ao auten-
ticador em relacao a credencial que sera apresentada. Quanto ao PAE agindo como
autenticador, ele e responsavel pela comunicacao com um suplicante e pelo repasse de
credenciais ao servidor de autenticacao. A figura 2.6 apresenta o local de operacao de
algumas PAEs localizadas em um dispositivo cliente e em cada porta de um equipamento
de rede.
Figura 2.6: Modelo de rede IEEE 802.1X destacando a localizacao das PAEs.
b) Protocolo de Comunicacao
Para promover a comunicacao entre as partes envolvidas, o padrao IEEE 802.1X faz
uso do protocolo EAP. Assim, a transmissao entre o autenticador e servidor de auten-
ticacao ocorre atraves do encapsulamento do EAP dentro do protocolo de comunicacao
12
do servidor. Alem disto, entre o suplicante e autenticador utiliza-se o EAP Over LANs
(EAPOL) - encapsulamento do EAP sobre protocolos na camada de enlace dentro do
conjunto de padroes de comunicacao IEEE 802.
Como pode ser visto na figura 2.7, o protocolo EAPOL consiste dos seguintes quatro
campos:
Versao: Possui tamanho de 1 byte (8 bits), serve como indicador de qual versao do
modelo IEEE 802.1X esta sendo empregada e, consequentemente, o significado dos
valores nos proximos campos;
A Wi-Fi Alliance, associacao internacional sem fins lucrativos responsavel pela certi-
ficacao de equipamentos wireless para redes locais (LANs) de acordo com o padrao IEEE
13
802.11, estabelece que produtos certificados deverao prover suporte para o IEEE 802.1X e
as diversas tecnicas de criptografia dentro do protocolo EAP, com destaque ao EAP-TLS,
EAP-TTLS e PEAP. Para tal finalidade, equipamentos com suporte para as tecnologias
WPA e WPA2, certificados pela Wi-Fi Alliance, possuem os modos de operacao WPA-
Enterprise e WPA2-Enterprise [WiFi-Alliance, 2005].
O padrao ASF e destinado para uso na monitoracao, gerenciamento e controle de
dispositivos com ou sem um sistema operacional de forma remota [DMTF, 2003].
Force Authorized : A porta esta liberada para qualquer conexao. Qualquer processo
de inicializacao de autenticacao pelo cliente e respondido com um pacote EAP-
Success;
14
No caso em que o suplicante nao receba nenhuma resposta de um possvel autenticador,
dentro de um perodo razoavel de tempo, ele devera assumir que a rede nao faz uso de
IEEE 802.1X, sendo assim ha liberacao direta de comunicacao.
O servidor de autenticacao ao receber a solicitacao devera avaliar se o acesso sera con-
cedido, negado ou requerer maiores informacoes de acordo com o funcionamento previsto
do protocolo EAP.
Apos o processo de autenticacao, uma chave dinamica podera ser sincronizada entre o
suplicante e o autenticador, atraves do uso de EAPOL-KEY, para prover maior seguranca
em meios mais susceptveis a interceptacao de dados (ex. redes sem fio). Esta operacao
so pode ser iniciada pelo autenticador.
A figura 2.8 representa as mensagens trocadas entre o suplicante e o autenticador em
relacao ao EAP, de acordo com o padrao IEEE 802.1X.
Figura 2.8: Comunicacao numa modelo basico cliente/servidor segundo o padrao IEEE
802.1X.
15
Autorizacao: Servico que de acordo com a identidade do usuario e/ou dispositivo
determina as permissoes e restricoes de um novo ingressante;
Por ser modulado e nao definir quais tecnologias deverao ser utilizadas, a arquite-
tura AAA e capaz de prover escalabilidade, flexibilidade e uma plataforma para a im-
plementacao de protocolos de autenticacao padronizados, como o Kerberos e o RADIUS
[Neuman et al., 2005].
Figura 2.9: Modelo basico de uma rede demonstrando a area de atuacao direta do padrao
802.1X e o protocolo RADIUS.
16
Um novo protocolo, Diameter, vem sendo desenvolvido para expandir as funcionali-
dades atuais do RADIUS e agir como seu sucessor. O Diameter faz uso de TLS para
criptografar todo o conteudo dos pacotes transmitidos e prover maiores informacoes dos
clientes ao servidor, alem de outros benefcios que se tornarao possveis com o fim da
elaboracao do protocolo [IETF, 2010].
Pacotes do protocolo RADIUS sao transmitidos contendo cinco campos com as se-
guintes funcoes (veja figura 2.10):
Codigo: Contendo oito bits e utilizado para definir qual o tipo do pacote RADIUS
sendo transmitido. A seguir e apresentado uma lista dos tipos de pacotes essenciais
para o processo de autenticacao [Rigney et al., 2000]:
Access-Request:
Unico tipo de pacote transmitido pelo cliente;
Access-Accept;
Access-Reject;
Access-Challenge;
17
Quando transmitido pelo cliente o campo e constitudo por um valor aleatorio,
imprevisvel e unico dentro do tempo de vida de uso da chave compartilhada
entre o cliente e o servidor;
Quando transmitido pelo servidor o campo e constitudo pelo resultado de uma
operacao MD5 calculado em cima dos valores dos campos codigo, identi-
ficacao, tamanho e atributos com o valor do campo autenticador trans-
mitido pelo cliente e a chave compartilhada. Caso o cliente receba um pacote
que gere um resultado diferente do esperado, o pacote devera ser descartado;
b) Autenticacao
18
Figura 2.11: Comunicacao entre um NAS e um servidor RADIUS segundo o padrao IEEE
802.1X.
c) Atributos
19
Nome ID Tipo Descricao
User-Password 2 Caso outra forma de autenticao nao seja utilizada,
este atributo contem a senha do usuario sendo au-
tenticado. O seu valor e criptografado utilizando o
algoritmo MD5 com a chave compartilhada entre
o NAS e o servidor RADIUS.
NAS-IP-Address 4 Transmite o endereco IP do NAS.
NAS-Port 5 Identifica qual porta fsica do NAS que o usuario,
que deseja se autenticar, esta conectado.
Reply-Message 18 Transmite um texto do servidor RADIUS para ser
apresentando ao usuario.
Vendor-Specific 26 Alocado para prover suporte a atributos especficos
de fabricantes. O campo valor citado anterior-
mente, e dividido em dois, sendo que a primeira
parte contem um outro numero de identificacao, e
a segunda parte os dados relacionados.
Session-Timeout 27 Define o tempo maximo, em segundos, que a sessao
de autenticacao devera ser mantida.
Idle-Timeout 28 Determina o tempo maximo consecutivo, tambem
em segundos, que conexao pode permanecer ociosa
antes que seja interrompida.
Calling-Station-Id 31 Identificacao do NAS, por exemplo, o numero fsico
da interface. No caso de redes LANs e WANs e o
numero do Media Access Control (MAC).
NAS-Identifier 32 Transmite uma cadeia de caracteres contendo o
nome atribudo ao NAS.
NAS-Port-Type 61 Indica o tipo de porta que o cliente esta conectado
ao NAS (ex. sem-fio, Ethernet e virtual).
EAP-Message 79 Atributo que transporta um pacote do protocolo
EAP. No uso do IEEE 802.1X a mensagem do su-
plicante e retransmitida ao servidor dentro deste
atributo [Aboba e Colhoun, 2003].
20
2.6.2 Network Access Protection
Os criterios de concessao de acesso de um servidor RADIUS podem ser extendidos, por
meio de integracao com um servidor de NAP, para avaliar o estado de execucao dos dispo-
sitivos dos usuarios. O NAP, tecnologia desenvolvida pela Microsoft Corporation, avalia
criterios relacionados a seguranca como, por exemplo, a existencia antivrus e atualizacoes
do sistema operacional [Morimoto et al., 2008].
Baseado na implementacao de uma Application Programming Interface (API), uma
aplicacao no dispositivo do usuario deve estar atenta a transmissao de uma lista de
criterios, oriundos do servidor, que devem ser avaliados e seu resultado transmitido du-
rante um processo de autenticacao.
Um servico cliente do NAP e disponibilizado, por padrao, nos sistemas operacionais
Windows XP Service Pack 3, Vista e 7. Solucoes para sistemas Linux existem no mercado,
porem, requerem a compra de uma licenca para cada equipamento.
21
2.7 Virtual LAN
De forma a prover acesso transparente e isolado a diversas redes dentro de uma mesma
infraestrutura fsica, o padrao IEEE 802.1Q preve a alocacao de dispositivos em Virtual
LANs (VLANs) na camada de enlace, disponibilizado atraves dos ativos de rede como,
por exemplo, switches e APs [IEEE-Computer-Society, 2006].
No IEEE 802.1Q, cada porta dos ativos de rede, seja ela real ou logica, e alocada
a uma ou mais VLANs, e somente havera a retransmissao de pacotes entre portas que
possuem uma mesma VLAN. Entre os equipamentos que provem suporte ao padrao, uma
marcacao e adicionada em todos os pacotes transmitidos para informar de qual VLAN(s)
ele originou. Ao propagar o pacote para uma estacao cliente ou equipamento sem suporte,
todas as marcacoes devem ser removidas. A identificacao da VLAN e um numero inteiro
entre 1 e 4095.
Administradores de rede utilizando-se desta tecnologia em conjunto com um servi-
dor NAP podem definir que, por exemplo, dispositivos que nao respeitam um lista de
exigencias terao seu ingresso na rede rejeitado, ou sejam alocados em uma VLAN de re-
mediacao. Esta VLAN visa isolar sistemas para evitar expor outros equipamentos na rede
a riscos de seguranca, sem impedir o acesso a servicos essenciais por meio dos quais os
dispositivos reprovadas possam se adequar as polticas vigentes.
O protocolo RADIUS, para prover suporte a VLANs no processo de autenticacao,
faz uso de tres atributos definidos por Zorn et alii [2000] e descritos na tabela 2.3. Os
atributos citados sao destinados ao uso de tunelamento - uma conexao dentro de outra,
como uma subrede virtual dentro de uma rede fsica.
22
Nome ID Tipo Descricao
Tunnel-Private-Group-ID 81 Define o nome ou numero de identificacao de
uma determinada sessao tunelada. O numero
de identificacao de uma VLAN e transmitido
neste atributo.
23
Captulo 3
Ambiente de Implementacao
Blocos de Aula 1 e 2: Contendo tres andares cada, foram projetados com o objetivo
principal de prover as salas de aula de todos os cursos. O Bloco de Aula 2 tambem
possui laboratorios de informatica;
24
Biblioteca: Contem a biblioteca e seu acervo, a direcao do campus, coordenacoes e
um laboratorio de informatica, alocados nos quatro pisos do edifcio;
25
Figura 3.2: Conexoes dos racks centrais com o nucleo de rede numa topologia em estrela.
As conexoes de rede sem-fio sao gerenciadas por 12 APs, todos com suporte a IEEE
802.1X e RADIUS, conforme os modelos apresentados adiante:
26
4 sao da marca D-Link: tres do modelo DI-524 e um DI-624;
27
Servico de Rede Descricao
Certificate Authority (CA) Servico de armazenamento e criacao de certificados.
Correio Eletronico Servidor de caixa de entrada e retransmissao de men-
sagens eletronicas, e-mail.
Domain Name System Servico de traducao de nomes por enderecos IP.
(DNS)
Servidor de Arquivos Prove o armazenamento de programas, documen-
tos e outros arquivos de uso comum da comunidade
academica.
Servidor de Instant Messa- Atende programas de mensagens instantaneas de uso
ging (IM) institucional.
Web Proxy Servico de controle de consumo de banda e acesso
a paginas web pelo qual obrigatoriamente todas co-
nexoes devem passar quando forem destinadas a en-
derecos externos em relacao ao campus.
Repositorio Proxy Debian Disponibiliza acesso a pacotes de instalacao do for-
mato Debian (deb) localmente. Caso um pacote nao
armazenado seja solicitado, ele sera baixado da In-
ternet e armazenado para atender a solicitacao atual
e outras futuras. O sistema operacional Ubuntu faz
uso de pacotes deb.
Servidor Web Prove hospedagem de paginas web e arquivos das co-
ordenacoes e setores administrativos do CAC/UFG.
Banco de Dados Uma base de dados de uso por aplicativos e outros
servicos de rede como um Servidor Web;
File Transfer Protocol Servico de transmissao remota de arquivos, usado
(FTP) principalmente no gerenciamento das paginas arma-
zenadas no Servidor Web.
Diversos servicos de rede (ex. servidor de arquivos e FTP) fazem uso de autenticacao
para regular o acesso de usuarios. Com o intuito de minimizar a complexidade de gerenci-
amento da rede, a base de usuarios e suas permissoes sao armazenadas em um servidor de
autenticacao centralizado, baseado na tecnologia de AD - como apresentado no captulo
2, secao 2.6.3. Os servicos de rede direcionam as tentativas de autenticacao de clientes ao
servidor AD, por meio do protocolo Kerberos conforme operacao descrita no captulo 2,
secao 2.4.2. A figura 3.3 apresenta uma estrutura simplificada do processo de autenticacao
encontrada no campus.
28
Figura 3.3: Estrutura simplificada de autenticacao para servicos utilizando uma base
centralizada de concessao de permissoes.
De todos os servicos, o acesso aos servidores de DHCP, DNS e Web Proxy sao consi-
derados essenciais para prover um uso basico da infraestrutura de rede alem nao exigirem
autenticacao.
29
a principal causa de reclamacoes de usuarios com dispositivos contendo o sistema opera-
cional Windows. Tais programas interferem no pleno funcionamento do sistema gerando
lentidao, corrupcao de dados, perdas de senhas, inacessibilidade de perifericos e ate mesmo
impedem a inicializacao do Windows. Ferramentas e atualizacoes do sistema operacional,
como apresentadas no captulo 2 - secao 2.2.3, sao frequentemente ausentes ou desatuali-
zados, inaptos a liderem com ameacas mais recentes.
O constante crescimento do numero de dispositivos no campus torna a rede susceptvel
a broadcast storms - tempestades de mensagens destinadas a todos. O uso destas men-
sagens e inerente ao funcionamento de diversos protocolos e servicos de rede autenticos,
como o DHCP, portanto sao essenciais e beneficas, exceto quando geradas por interfaces
defeituosas ou programas maliciosos. A existencia de centenas de dispositivos trans-
mitindo estes pacotes - que trafegam em toda a rede, e capaz de afetar diretamente a
capacidade dos equipamentos de rede e dispositivos de usuarios a lidarem com os pacotes
recebidos.
O ponto crtico do efeito de broadcast storm e uma rede incapaz de promover co-
municacao confiavel ou se tornar inutilizavel. Solucoes para este problema visam a seg-
mentacao de uma rede em sub-redes sendo que mensagens broadcast nao trafegam entre
elas, ou limitar trafego destes pacotes nos equipamentos de rede.
30
Captulo 4
Implementacao
Apos citar diversas tecnologias para prover controle de acesso a rede e apresentar a
estrutura de rede do CAC/UFG, neste captulo e documentado um projeto de imple-
mentacao que visa solucionar os problemas de seguranca encontrados na rede do campus,
atraves do uso de NAC. A estrutura geral da solucao NAC, a implementacao de seus
servidores e as configuracoes de todos equipamentos envolvidos sao apresentados a seguir.
4.1 Projeto
Para adotar o uso de tecnologias de controle de acesso a rede, um servidor RADIUS
foi configurado e integrado com o servidor de domnio do campus (AD) e um servidor
NAP. A integracao com o servidor AD visa trabalhar segundo a estrutura de autenticacao
centralizada do campus, utilizando o protocolo Kerberos.
O servidor de polticas de seguranca NAP e responsavel por verificar se o dispositivo
solicitando acesso a rede possui antivrus instalado e atualizado, firewall habilitado e
todas as atualizacoes crticas de seguranca do sistema operacional. O servidor RADIUS
avaliara a capacidade dos suplicantes em realizar as consultas do servidor NAP. A figura
4.1 exibe o local de atuacao das tecnologias utilizadas pelo projeto dentro de um modelo
simplificado cliente/servidor.
31
Alem disto, todo novo ingressante sera alocado em uma de duas VLANs possveis:
VLAN 2 e 3. A VLAN 2 e destinada a dispositivos aprovados pelas polticas de seguranca
e sao ditos seguros, enquanto a VLAN 3 - de remediacao, e destinada a todos os supli-
cantes reprovados pelo NAP. Caso o sistema operacional do cliente nao possua suporte as
consultas do servidor NAP, mas as credenciais fornecidas sejam aprovadas, o suplicante
sera alocado na VLAN 2.
Dentre todas as tecnicas de criptografia comuns, utilizadas por meio do protocolo
EAP e descritas no captulo 2, as solucoes adotadas foram o PEAP e MS-CHAPv2.
Trabalhando em conjunto, o PEAP estabelecera uma conexao segura, por meio da qual
o MS-CHAPv2 fornecera as credenciais dos usuarios. A primeira razao pela escolha se
deve ao suporte existente a tecnica pelos sistema operacionais Windows e Linux utilizados
dentro do CAC/UFG. Uma segunda razao e sua menor complexidade de implementacao
em relacao a solucoes mais robustas como o EAP-TLS, que exige a criacao e distribuicao de
um certificado para cada cliente. Contudo, suporte ao uso de certificados pelos suplicantes
tambem sera aceito como mecanismo de autenticacao.
O processo de autenticacao sera composto por tres conjuntos de regras, avaliados em
sequencia:
Caso um suplicante nao seja aprovado por uma regra, ele sera avaliado por uma se-
gunda ate que seja aprovado ou rejeitado por todos. A avaliacao por mais de uma regra
nao implica na retentativa de autenticacao e sim na reavaliacao do suplicante, de acordo
com informacoes fornecidas pelo mesmo. Todos os processos de autenticacao sao registra-
dos em conjunto com a regra aplicada ou a informacao de que foi rejeitado.
32
PEAP adotada pelo projeto, ao servidor NPS foi alocado um certificado gerado pela
autoridade de certificados (CA - Certificate Authority) do domnio.
O servidor NAP adotado, para qual o NPS fornece integracao, e o Health Registra-
tion Authority (HRA) que e disponibilizado no conjunto de servicos e ferramentes que
acompanham o sistema operacional escolhido. O HRA tem sido a escolha de imple-
mentacao adotado pela industria para a avaliacao de dispositivos clientes em redes com
NAC [Tulluch, 2007].
Polticas de Rede: As condicoes e regras que devem ser respeitadas para ter o
acesso aprovado.
Figura 4.2: Definicao dos metodos de criptografia que o servidor devera reconhecer.
Em seguida, duas Polticas de Saude foram criadas sendo uma para determinar
se o dispositivo suplicante foi aprovado e outra se foi rejeitado. Neste projeto, todas as
33
verificacoes do servidor HRA devem se respeitadas, porem, existe a opcao de basear a
concessao de acesso em situacoes intermediarias em que o cliente respeite ou nao, uma ou
mais poltica(s) do HRA. Quanto a lista de elementos que o servidor HRA devera avaliar,
estes foram definidos junto aos criterios de polticas para dispositivos com Windows,
encontrado via a navegacao na arvore do painel do servidor.
Baseando-se no significado das Polticas de Saude, as Polticas de Rede foram
criadas segundo as tres regras definidas pelo projeto. Alem disso, cada poltica foi configu-
rada para transmitir os atributos RADIUS para informar o autenticador sobre qual VLAN
o suplicante sera alocado caso seja aprovado. Os atributos sao abordados no captulo 2,
na secao 2.7, enquanto as etapas de configuracao sao demonstradas na figura 4.3.
Figura 4.3: Etapas para configurar os atributos RADIUS para alocacao de VLANs.
4.4 Autenticadores
A todos os equipamentos de rede, ou NAS como denominados pelo protocolo RADIUS,
deverao ser alocados um endereco IP e uma chave secreta. As chaves, preferencialmente
unicas para cada NAS, aleatorias e de tamanho consideravel, deverao ser cadastradas no
servidor NPS, em conjunto com o endereco IP de cada equipamento. Caso haja uma
conexao para o servidor oriunda de um endereco desconhecido e/ou com chave errada,
a solicitacao sera silenciosamente descartada (sem transmissao de qualquer resposta) e
registrada.
Os NAS deverao tambem ser configurados para transmitir mensagens RADIUS para o
endereco do servidor e sua respectiva porta do protocolo UDP. Pela definicao do protocolo
RADIUS, a porta padrao para autenticacao e a 1812.
34
Apos a configuracao inicial, switches devem passar por uma averiguacao de quais
portas serao usadas por estacoes de trabalho de usuarios e quais realizam interconexao
com outros NAS. Para as estacoes de trabalho, as portas serao configuradas com o estado
de execucao Auto, e as de interconexao no estado Force Authorized. Como a alocacao das
VLANs dos suplicantes e feita dinamicamente via RADIUS, cabe apenas criar as VLANS
e definir que na comunicacao com outros NAS devera haver marcacao nos pacotes.
Quanto aos APs, deve-se avaliar se possuem suporte ao IEEE 802.1Q. Em caso nega-
tivo, a porta do switch na qual o AP esta conectado devera ser configurada para transmitir
somente pacotes da VLAN 3, sem marcacao, de forma a nao prejudicar a seguranca dos
equipamentos na VLAN 2. Para configurar as informacoes do servidor de autenticacao,
devera ser selecionada a opcao de criptografia WPA2-Enterprise ou, caso nao possua,
WPA-Enterprise.
De todos os APs que pertencem ao campus, somente os da marca RouterBoard e
3COM possuem suporte a IEEE 802.1Q e portanto recomenda-se a substituicao dos outros
por modelos destes fabricantes ou outros que fornecam suporte ao padrao. Porem, na
escolha dos modelos de equipamentos deve ser avaliada a quantidade maxima esperada de
usuarios que poderao usufruir da rede sem fio, pois um AP sobrecarregado sera incapaz
de autenticar novos usuarios.
No switch backbone, no nucleo da rede, as portas responsaveis pelas conexoes com
os servidores dos servicos DHCP, DNS e Web Proxy (descritos no captulo 3), devem
ser configuradas para transmitir pacotes de todas as VLANS sem marcacao. Acesso aos
outros servicos de rede ficam restritos a VLAN 2, tambem sem marcacao.
4.5 Suplicantes
Como apresentados no captulo anterior, o campus adota o uso dos sistemas operaci-
onais Windows XP, Vista, 7 e Linux da distribuicao Ubuntu.
Nao provendo suporte ao NAP, o sistema Ubuntu devera apenas ter suas conexoes de
rede configuradas para realizar autenticacao IEEE 802.1X, como indicado pelas figuras
4.4 e 4.5.
35
Figura 4.5: Janelas de edicao de conexoes de rede para prover autenticacao IEEE 802.1X.
Por padrao os servicos de autenticacao IEEE 802.1X e cliente NAP sao fornecidos nos
sistemas operacionais Windows, porem se encontram desativados. Cabe aos administra-
dores ativarem e configurarem os servicos Configuracao Automatica de Rede com Fio e
Agente de Network Access Protection (NAP) manualmente, via um script ou, no caso
de dispositivos integrados ao domnio, com a criacao de uma diretiva.
O Windows XP possui as opcoes de trabalhar com autenticacao baseada em MD5,
certificados e PEAP-MSCHAPv2. O MD5 consiste em atribuir a responsabilidade de
criptografia ao mecanismo padrao do protocolo EAP. A opcao de utilizar certificados e
baseada em TLS, porem, exige um certificado distinto para cada cliente, armazenado em
um Certificate Authority (CA). Os sistemas Windows Vista e 7 nao possuem a opcao de
usar o MD5.
Para habilitar a verificacao NAP, atraves da janela de configuracoes da interface de
rede, a opcao verificacao de quarentena foi selecionada. Em dispositivos que nao per-
tencem ao domnio, o nome do dispositivo e/ou usuario nao devera ser utilizado para
autenticar, que e o padrao do servico - veja figura 4.6. A remocao desta opcao provocara
o surgimento de um aviso proximo a barra de tarefas que, ao ser clicado, exibe uma janela
solicitando que o usuario forneca suas credenciais para iniciar o processo de autenticacao.
Caso o dispositivo nao seja aprovado na consulta das polticas de seguranca do NAP,
um aviso tambem sera exibido alertando o usuario sobre os problemas encontrados que
nao foram possveis corrigir automaticamente pelo cliente NAP, e que o dispositivo se
encontra numa rede de remediacao. O usuario podera, pela janela de avisos, solicitar uma
reavaliacao do estado do dispositivo e enviar o novo resultado ao servidor na esperanca
de ser aprovado e concedido acesso a rede segura.
36
Figura 4.6: Janela contendo as opcoes de configuracao do processo de autenticacao em
dispositivos com Windows.
37
Captulo 5
Testes
38
Quantidade media de falhas de autenticacao, caso haja;
5.4 Resultados
De acordo com a realizacao dos testes e possvel afirmar que o recurso mais crtico
para prover autenticacao e o processador e sua velocidade. As tentativas de autenticacao
geraram uma media de 4%, 10%, 16,5% respectivas ao primeiro, segundo e terceiro teste no
servidor RADIUS. Por sua parte, o servidor de domnio sofreu um carga media de 2%, 5%,
8,5%. A figura 5.1 contem um grafico apresentando a variacao da taxa de processamento
real dos servidores, de acordo com a porcentagem media, durante cada teste.
Entre a transmissao da solicitacao de autenticacao e sua resposta, os servidores foram
capazes de manter uma media constante de 0,08 segundos, sem a ocorrencia de qualquer
erro de autenticacao. Todos os registros de tentativas de autenticacao e seus resultados
foram armazenados com sucesso em disco, consumindo um total de 5,26GB, sendo que
cada uma das 900.000 tentativas realizadas ocuparam aproximadamente 6,13KB.
39
Figura 5.1: Grafico apresentando a variacao de processamento durante a execucao dos
testes.
40
Captulo 6
Conclusoes Finais
41
usuarios do campus, um servidor AD, demonstraram a capacidade do servico de auten-
ticacao de lidar simultaneamente com milhares de requisicoes, muito alem da quantidade
total de alunos, professores e tecnicos administrativos da unidade academica.
O projeto teve sua implementacao aplicada ao CTI e nucleo da rede para avaliacao,
porem, dado sua escalabilidade pode ser implantado para atender a todos os dispositivos
do campus.
42
Referencias
ABOBA, B.; COLHOUN, P. RADIUS (Remote Authentication Dial In User Service)
Support For Extensible Authentication Protocol (EAP). Internet Engineering Task Force
RFC 3579. 2003.
ABOBA, B.; SIMON, D. PPP EAP TLS Authentication Protocol. Internet Engineering
Task Force RFC 2716. 1999.
ALLIED-TELESIS. 802.1x White Paper. Bothell, WA, USA: Allied Telesis, Inc. 2006.
BURNETT, S.; PAINE, S. Criptografia e Seguranca - O Guia Official RSA. Rio de Ja-
neiro: Editora Elsevier, 2002.
CISCO-SYSTEMS. Cisco IOS Security Configuration Guide. San Jose, CA, USA: Cisco
Systems, Inc., 2006.
CISCO-SYSTEMS. Network Security Policy: Best Practices White Paper. San Jose, CA,
USA: Cisco Systems, Inc. 2007.
DANTU, R.; CLOTHIER, G.; ATRI, A. EAP methods for wireless networks. Computer
Standards & Interfaces Volume 29, Issue 3, p. 289-301, Editora Elsevier B. V. 2007.
DIAS, J. A Guide to Microsoft Active Directory (AD) Design. Livermore, CA, USA:
Lawrence Livermore National Laboratory. Relatorio tecnico interno. 2002.
DMTF. Alert Standard Format Specification version 2.0. Distributed Management Task
Force, Inc. 2003.
HASSELL, J. Learning Windows Server 2003. 2nd. edicao. ed. Sebastopol, CA, USA:
Editora OReilly, 2006.
43
IEEE-COMPUTER-SOCIETY. Port-Based Network Access Control: IEEE Std 802.1X-
2004. Institute of Electrical and Electronics Engineers Standard for Local and Metropo-
litan Area Networks. 2004.
IETF. Diameter Maintenance and Extensions (dime) - Working Group. Disponvel em:
<http://datatracker.ietf.org/wg/dime/charter/>. Acesso em 10 de abr. 2010.
LAAT, C. de et al. Generic AAA Architecture. Internet Engineering Task Force RFC
2903. 2000.
LOPEZ, G. et al. A network access control approach based on the AAA architecture and
authorization attributes. Journal of Network and Computer Applications Volume 30,
Issue 3, p. 900-919, Editora Elsevier B. V. 2007.
MORIMOTO, R. et al. Windows Server 2008 Unleashed. Indianapolis, IN, USA: Sams
Publishing, 2008.
NEUMAN, C. et al. The Kerberos Network Authentication Service (V5). Internet Engi-
neering Task Force RFC 4120. 2005.
POTTER, B. Conversing wired and wireless authentication. 2007. Network Security Vo-
lume 2007, Issue 10, p. 18-20, Editora Elsevier Ltd.
SHAPIRO, J. R.; BOYCE, J. Windows Server 2003 Bible - R2 and SP1 Edition. India-
napolis, IN, USA: Wiley Publishing, Inc., 2006.
44
SIMPSON, W. PPP Challenge Handshake Authentication Protocol (CHAP). Internet En-
gineering Task Force RFC 1994. 1996.
TANENBAUM, A. S. Redes de Computadores. 4a.. ed. Sao Paulo: Elsevier Editora Ltda.,
2003.
TULLUCH, M. Introducing Windows Server 2008. Redmond, WA, EUA: Editora Micro-
soft Press, 2007.
ULBRICH, H. C.; VALLE, J. D. Universidade Hacker. 6a. ed. Sao Paulo: Editora Digerati
Books, 2009.
WANG, X.; YU, H. How to Break MD5 and Other Hash Functions. Advances in Crypto-
logy - EUROCRYPT 2005, Volume 3494, p. 19-35. Editora Springer. 2005.
WIFI-ALLIANCE. Deploying Wi-Fi Protected Access (WPA) and WPA2 in the Enter-
prise. Wi-Fi Alliance WPA and WPA2 Implementation White Paper. 2005.
ZORN, G. Microsoft PPP CHAP Extensions, Version 2. Internet Engineering Task Force
RFC 2759. 2000.
ZORN, G. et al. RADIUS Attributes for Tunnel Protocol Support. Internet Engineering
Task Force RFC 2868. 2000.
45
[Tanenbaum, 2003] [Allied-Telesis, 2006] [Dantu, Clothier e Atri, 2007] [Adoba et al., 2004]
[Lopez et al., 2007] [Romeiro, 2003] [Zorn et al., 2000]
46