Você está na página 1de 56

UNIVERSIDADE FEDERAL DE GOIAS UFG

CAMPUS CATALAO CAC

DEPARTAMENTO DE CIENCIA DA COMPUTACAO DCC

Bacharelado em Ciencia da Computacao

Projeto Final de Curso

Implementacao de 802.1X e RADIUS Integrado ao


Active Directory e Network Access Protection no
CAC/UFG

Autor: Rafael de Sales y Ulhoa

Orientador: Dr. Roberto Mendes Finzi Neto

Co-orientador: Luiz Fernando Elias Martinez

Catalao - 2010
Rafael de Sales y Ulhoa

Implementacao de 802.1X e RADIUS Integrado ao Active Directory e


Network Access Protection no CAC/UFG

Monografia apresentada ao Curso de


Bacharelado em Ciencia da Computacao da
Universidade Federal de Goias Campus Catalao
como requisito parcial para obtencao do ttulo de
Bacharel em Ciencia da Computacao

Area de Concentracao: Redes


Orientador: Dr. Roberto Mendes Finzi Neto
Co-orientador: Luiz Fernando Elias Martinez

Catalao - 2010
S. Ulhoa, Rafael

Implementacao de 802.1X e RADIUS Integrado ao Active Directory e


Network Access Protection no CAC/UFG/ Dr. Roberto Mendes Finzi
Neto/ Luiz Fernando Elias Martinez- Catalao - 2010

Numero de paginas: 45

Projeto Final de Curso (Bacharelado) Universidade Federal de Goias, Campus


Catalao, Curso de Bacharelado em Ciencia da Computacao, 2010.

Palavras-Chave: 1. Seguranca. 2. Network Access Control. 3. 802.1X


Rafael de Sales y Ulhoa

Implementacao de 802.1X e RADIUS Integrado ao Active Directory e


Network Access Protection no CAC/UFG

Monografia apresentada e aprovada em de


Pela Banca Examinadora constituda pelos professores.

Dr. Roberto Mendes Finzi Neto Presidente da Banca

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.

Palavras-Chaves: Seguranca, Network Access Control, 802.1X


Conteudo

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

2.1 Modelo cliente/servidor simplificado com um switch representando a infra-


estrutura. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Infraestrutura comprometida dentro de um modelo cliente/servidor. . . . . 4
2.3 Dispositivo cliente comprometida dentro de um modelo cliente/servidor. . . 5
2.4 Estrutura das mensagens do protocolo EAP. . . . . . . . . . . . . . . . . . 8
2.5 Modelo basico de uma rede demonstrando a area de atuacao direta e as
tres entidades definidas pelo padrao 802.1X. . . . . . . . . . . . . . . . . . 12
2.6 Modelo de rede IEEE 802.1X destacando a localizacao das PAEs. . . . . . 12
2.7 Estrutura de pacotes do protocolo EAPOL. . . . . . . . . . . . . . . . . . 13
2.8 Comunicacao numa modelo basico cliente/servidor segundo o padrao IEEE
802.1X. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.9 Modelo basico de uma rede demonstrando a area de atuacao direta do
padrao 802.1X e o protocolo RADIUS. . . . . . . . . . . . . . . . . . . . . 16
2.10 A estrutura de um pacote do protocolo RADIUS . . . . . . . . . . . . . . . 17
2.11 Comunicacao entre um NAS e um servidor RADIUS segundo o padrao
IEEE 802.1X. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1 Desenho da localizacao dos edifcios. . . . . . . . . . . . . . . . . . . . . . 25


3.2 Conexoes dos racks centrais com o nucleo de rede numa topologia em estrela. 26
3.3 Estrutura simplificada de autenticacao para servicos utilizando uma base
centralizada de concessao de permissoes. . . . . . . . . . . . . . . . . . . . 29

4.1 Locais de atuacao das tecnologias utilizadas pelo projeto. . . . . . . . . . . 31


4.2 Definicao dos metodos de criptografia que o servidor devera reconhecer. . . 33
4.3 Etapas para configurar os atributos RADIUS para alocacao de VLANs. . . 34
4.4 Localizacao da opcao para abrir o gerenciador de redes. . . . . . . . . . . . 35
4.5 Janelas de edicao de conexoes de rede para prover autenticacao IEEE 802.1X. 36
4.6 Janela contendo as opcoes de configuracao do processo de autenticacao em
dispositivos com Windows. . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

iii
5.1 Grafico apresentando a variacao de processamento durante a execucao dos
testes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

iv
Lista de Tabelas

2.1 Lista de tecnicas de criptografia do protocolo EAP . . . . . . . . . . . . . 9


2.2 Lista de atributos RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3 Lista de atributos RADIUS utilizados para implementar VLANs . . . . . . 22

3.1 Lista dos servicos de rede do CAC/UFG . . . . . . . . . . . . . . . . . . . 27

v
Captulo 1

Consideracoes Iniciais

Na mesma medida em que redes de organizacoes vao se expandindo, a complexidade


de gerenciar o uso da infraestrutura e o estado de execucao dos dispostivos dos usuarios
tambem aumenta. A ausencia de registros de acesso contribuem para a acao de malfeito-
res que dificilmente sao identificados. Dispostivos de usuarios sao ainda frequentemente
contaminados com programas maliciosos, comprometendo dados sigilosos e o pleno fun-
cionamento do equipamento.
Com o intuito de prover controle de acesso e contabilidade, surgiram padroes e tecnolo-
gias como o 802.1X e o protocolo Remote Authentication Dial-In User Service (RADIUS),
por meio dos quais todos os usuarios ao desejarem ingressar na rede lhes sao solicitados a
fornecerem credenciais antes que tenham qualquer acesso aos servicos de rede. Quanto aos
dispositivos, a existencia de programas e atualizacoes de seguranca podem ser consultadas
por um servidor de Network Access Protection (NAP), de forma a permitir o isolamento
de estacoes de trabalho com seguranca comprometida.
Este trabalho documenta as tecnologias citadas anteriormente, que foram utilizadas
para implementar controle de acesso na rede do campus Catalao da Universidade Federal
de Goias, que faz uso de um servidor de autenticacao centralizado, baseado em Active
Directory (AD), para os seus servicos de rede.
O captulo 2 aborda conceitos gerais sobre seguranca, tecnicas e protocolos de cripto-
grafia alem de tratar de tecnologias de controle de acesso a rede e servidores de auten-
ticacao utilizados no decorrer do trabalho.
A estrutura e caractersticas da rede interna do campus sao citadas no captulo 3,
em conjunto com uma lista de servicos de rede e problemas de seguranca existentes. O
ambiente de rede do campus sera o local de implementacao do projeto apresentado neste
trabalho, conforme descrito no captulo 4.
Para avaliar a capacidade de operacao dos servidores de autenticacao utilizados pelo
projeto, conjuntos de testes foram realizados e descritos no captulo 5, junto com os
resultados obtidos. Por fim, no captulo 6 sao apresentadas as conclusoes do trabalho.

1
Captulo 2

Estado da Arte

Neste captulo sao abordados tecnologias de seguranca para redes de computadores


cuja explicacao e indispensavel para a compreensao do projeto de implementacao desen-
volvido neste trabalho. Inicialmente sao abordados os objetivos de uma rede e criterios
basicos que devem ser respeitados para prover seguranca e confidenciar as informacoes
transmitidas. Em seguida sao descritas tecnicas e protocolos de criptografia necessarios
para prover seguranca no uso de controle de acesso a rede. Por ultimo, sao apresentadas
diversas tecnologias de servidores de autenticacao, as quais serao utilizadas pelo projeto de
forma a prover mecanismos de avaliacao de crendenciais de usuarios e o estado execucao
dos dispositivos.

2.1 Redes de Computadores


Desde o surgimento de computadores o seu uso vem-se tornando um fato inevitavel,
principalmente nas ultimas duas decadas com o aumento da capacidade de armazenar e
computar informacoes. Contudo, originalmente cada computador possua uma lista de
perifericos que somente ele poderia usufruir. Um exemplo classico diz respeito ao uso de
impressoras que exigia o transporte de arquivos, via uma forma de armazenamento qual-
quer, ate o dispositivo detentor do periferico para realizar a impressao de documentos.
A princpio, uma solucao era comprar e instalar impressoras para todas as estacoes de
trabalho. O alto custo de implementacao estimulou a busca por uma forma de interco-
nectar dispositivos de forma a permitir que varios dispositivos tenham acesso a um unico
periferico. Assim surgiu o conceito de redes de computadores [Tanenbaum, 2003].
Baseado em conjuntos de tecnicas e tecnologias, as redes foram criadas, como o exem-
plo anterior indica, para o compartilhamento de recursos. Contudo, novas aplicacoes para
tais interconexoes continuam a surgir a fim de tornarem a vida e o trabalho do ser humano
cada vez mais pratico [Zapater e Suzuki, 2005].
Segundo Tanenbaum [2003], o uso de redes de computadores segue 4 objetivos:

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;

Disponibilidade de um meio de comunicacao eficiente, seja via e-mail, com audio ou


videoconferencia que possa suprir a maioria das necessidades diarias de comunicacao;

Realizar negocios eletronicos com empresas;

Realizar negocios com consumidores via internet, ou seja, o comercio eletronico.

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.

Figura 2.1: Modelo cliente/servidor simplificado com um switch representando a infraes-


trutura.

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].

Figura 2.2: Infraestrutura comprometida dentro de um modelo cliente/servidor.

Quanto ao controle de acesso a rede, ou Network Access Control (NAC), existem


diversas solucoes que fornecem mecanismos de controle como Access Points (APs), que
podem exigir o uso de senha para usufruir de uma rede sem-fio. Em redes cabeadas
esse controle pode ser feito por meio de tecnologias fornecidas em switches denominados
gerenciaveis, isto e, que concedem a capacidade de definir o modo de operacao de cada
porta disponvel no equipamento.

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].

Figura 2.3: Dispositivo cliente comprometida dentro de um modelo cliente/servidor.

Quantidades consideraveis destes programas maliciosos podem ser evitados e elimi-


nados atraves do uso de programas antivrus, anti-spyware (ferramentas anti-programas
de espionagem), firewall e atualizacoes de seguranca do sistema operacional. Enquanto
as duas primeiras solucoes agem diretamente sobre a existencia do perigo no dispositivo,
firewalls visam controlar o acesso de programas entre a rede e o dispositivo hospedeiro.
Atualizacoes de seguranca tem por meta principal corrigirem erros e vulnerabilidades
encontrados no sistema operacional.
A verificacao dos criterios supre-citados e denominada de Polticas de Seguranca de
Rede (Network Security Policy) e sao frequentemente utilizados em conjunto cas creden-
ciais do usuario no controle de acesso a rede local. Solucoes como o Network Access
Protection (NAP), abordado adiante no trabalho, sao capazes de restringir ou isolar o
acesso de dispositivos que nao respeitam as polticas [Cisco-Systems, 2007]

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.

2.3.1 Message-Digest Algorithm 5


O Message-Digest Algorithm 5 (MD5) e uma funcao de hash criptografico usado po-
pularmente para determinar a integridade de arquivos. Tecnicas de hashing criptograficos
recebem uma entrada de tamanho qualquer e retornam um valor binario contendo sempre
o mesmo tamanho (um hash), no caso do MD5 a sada e de 128 bits. Apesar de ser apto a
criptografar senhas, o MD5 ja foi apontado como pouco resistente a ocorrencia de colisoes,
ou seja, quando duas entradas diferentes (ex. senhas) geram a mesma sada (ex. arquivo
descriptografado) [Wang e Yu, 2005].

2.3.2 Certificados Digitais


Nesta tecnica de criptografia se utiliza uma entrada de dados, consideravelmente
grande e aleatoria, para gerar duas chaves: uma publica e outra privada. Como o proprio
nome indica, o acesso a chave publica e disponibilizado para todos que o desejam. Alem
disto, a principal funcao da chave public e atuar no processo de criptografia dos dados.
O processo inverso somente e possvel com o uso da chave privada. Assim, um cliente
que utiliza a chave publica e apto a assumir que somente o detentor do certificado, com
sua respectiva chave privada, sera capaz de reconhecer o conteudo de uma mensagem
transmitida.

2.3.3 Transport Layer Security


Sucessor do protocolo Secure Socket Layer (SSL), o Transport Layer Security (TLS)
e um sistema de criptografia de dados para camada de transporte do modelo TCP/IP,
provendo comunicacao segura entre duas dispositivos, frequentemente utilizado no modelo
cliente/servidor. Segundo o TLS, pelo menos um dos envolvidos precisa possuir um certi-
ficado para que as chaves publicas sejam compartilhadas e utilizadas para sincronizar uma
nova chave, definida de forma aleatoria, e determinar qual versao do TLS sera utilizado,
por ambos dispositivos, ate o finalizacao da conexao segura sendo estabelecidas.

2.3.4 Protocolos para o Acesso Sem Fio


Equipamentos que disponibilizam redes sem fio segundo o padrao 802.11, definido pelo
Institute of Electrical and Electronics Engineers (IEEE), fornecem algumas tecnicas de

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.

2.4.1 Challenge-Handshake Authentication Protocol


Criado originalmente para conexoes ponto a ponto como, por exemplo, acesso de linha
discada ou Digital Subscriber Line (DSL), o Challenge-Handshake Authentication Protocol
(CHAP) e uma tecnica de autenticacao de usuarios em que um servidor de autenticacao
transmite uma sequencia denominada de challenge. Esta sequencia devera ser processada
em conjunto com a senha do usuario por uma funcao de hash criptografico. O resultado
devera ser entao retransmitido ao servidor para analise e confirmacao. Tanto o cliente
quanto o servidor deverao ter a senha armazenada em puro texto (nao criptografado) e,
em intervalos aleatorios, o cliente devera ser reavaliado com um novo challenge. O CHAP
sofre do problema de colisoes presente em algoritmos como o MD5, portanto o seu uso
nao e recomendado como forma principal de autenticacao [Simpson, 1996].
Para extender as funcionalidades do protocolo CHAP a empresa Microsoft Corpora-
tion criou o MS-CHAP. Esta extensao dispoe de mecanismos de troca e retentativa de
transmissao da senha do usuario (via o uso de challenge) sem que haja uma reinicalizacao
no processo, alem da definicao de diversos codigos de identificacao de erros e o fim da
necessidade de armazenar a senha em puro texto. Atualmente o MS-CHAP se encontra
na versao 2 e presente nos sistemas operacionais da empresa operando em conjunto com
outras tecnicas (ex. certificados digitais), que estabelecem uma conexao segura por meio
da qual trabalha o MS-CHAP [Zorn, 2000].

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

A estrutura dos pacotes do protocolo EAP e dividida em quatro campos como apre-
sentado na figura 2.4 e descritos a seguir:

Figura 2.4: Estrutura das mensagens do protocolo EAP.

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:

1: Pacote do formato Request (Requisicao);


2: Do formato Response (Resposta);
3: Do formato Success (Sucesso);
4: Do formato Failure (Fracasso).

Identificador: Campo utilizado para auxiliar na identificacao entre um pacote de


requisicao e sua resposta. Contem tambem 1 octeto;

Tamanho: 2 octetos para indicar o comprimento total do pacote;

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

As tecnicas de criptografia mais comuns, como as apresentadas em algumas literaturas


(Allied Telesis [2006] e Dantu; Clothier; Atri [2007]), e descritas pela documentacao do
protocolo (Adoba et al. [2004]) estao apresentadas na tabela 2.4.3 com suas descricoes e
estrutura presentes no campo de dados em pacotes EAP.

Tabela 2.1: Lista de tecnicas de criptografia do protocolo EAP

Nome Estrutura e Descricao


Identity Constitudo do numero de identificacao 1 (ID 1). Em
pacotes Response ele e seguido por um campo contendo
o nome do usuario para qual esta havendo autenticacao.
Nak (Not acknowled- Contendo ID 3, seu uso e indicado quando o cliente
ged) nao reconhece a tecnica de autenticacao solicitada pelo
autenticador. Podera ser sucedido por um ou mais
numeros de identificacao das tecnicas desejadas. A
transmissao do ID 0 implica que o cliente desconhece
uma alternativa e que o processo devera ser encerrado.

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

O processo de autenticacao com o uso do protocolo EAP se inicia com a transmissao


de um pacote Request, da parte de um equipamento autenticador, ao cliente. Dentro do
pacote transmitido, no campo de dados esta contida a tecnica de criptografia que o
autenticador aguarda do cliente, juntamente com um pacote Response. Em seguida, o au-
tenticador devera processar ou repassar a resposta do cliente para outro equipamento apto
a analisar o pacote e determinar se o que o cliente sera aprovado (com a transmissao de
um pacote Success), negado (pacote Failure) ou que devera solicitar maiores informacoes
(pacote Request). A transmissao de sucesso ou fracasso e o fator determinante do final
do processo.
Caso o cliente nao reconheca a forma de autenticacao solicitada ele podera responder
com um pacote Response contendo o tipo de autenticacao Nak, para tentar negociar
uma segunda forma de autenticacao. Se o autenticador nao prover suporte para o metodo
solicitado ou nao permitir a negociacao, a solicitacao e automaticamente negada e o cliente
recebe uma transmissao Failure.

2.5 Network Access Control


Implementacoes de Network Access Control (NAC) visam isolar usuarios e/ou diposi-
tivos do resto da rede ate que apresentam credenciais validas e/ou se adequam as polticas
de seguranca vigentes na rede como, por exemplo, a existencia de uma programa antivrus
instalado [Potter, 2007].
Como forma de padronizar o uso de NAC entre fabricantes diferentes, a IEEE elaborou
e publicou um padrao de controle de acesso a rede em nvel de porta, o IEEE 802.1X.

2.5.1 IEEE 802.1X


O IEEE 802.1X, de uso comum tanto para redes cabeadas (IEEE 802.3) como wireless
(IEEE 802.11), define um padrao de autenticacao para o uso na interacao entre tres
entidades: suplicantes, autenticadores e um servidor de autenticacao.
Suplicantes sao os clientes (usuarios e seus dispositivos) que desejam ingressar na
rede, enquanto autenticadores sao equipamentos (ex. switch gerenciavel) responsaveis
por regular o acesso de suplicantes conectados nele. Segundo o padrao, o autenticador
e responsavel por solicitar as credenciais dos suplicantes e repassa-las a um servidor de
autenticacao, utilizando um protocolo proprio deste servidor, cuja implementacao nao e
definida [IEEE-Computer-Society, 2004]. As funcoes de autenticador e de servidor podem
ser desempenhadas pelo mesmo dispositivo, porem, a localizacao e a implementacao do

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.

a) Port Access Entity

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:

Figura 2.7: Estrutura de pacotes do protocolo EAPOL.

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;

Tipo: Indicacao do tipo de pacote EAPOL transmitido, cujo numero e armazenado


em 1 byte. A lista dos possveis tipos estao apresentados adiante;

EAP-Packet: Indica que um pacote do protocolo EAP esta sendo transmitido


no campo corpo;
EAPOL-Start: Utilizada pelo cliente para solicitar o inicio do processo de
autenticacao. Pacotes deste tipo nao possuem o campo corpo;
EAPOL-Logoff : Indica o desejo do usuario de se desautenticar. Tambem nao
possui o campo corpo;
EAPOL-Key: Pacotes deste tipo sao utilizados para sincronizar uma chave
dinamica entre o suplicante e o autenticador com informacoes transmitidas no
corpo do EAPOL;
EAPOL-Encapsulated-ASF-Alert: Indica que o Corpo do pacote contem uma
mensagem de alerta ou erro dentro do padrao Alert Standard Format (ASF);

Tamanho: 2 bytes utilizados para indicar o comprimento do proximo campo, em


octetos;

Corpo: O conteudo deste campo e determinado pelo tipo de pacote EAPOL.

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].

c) Visao Geral de Operacao

Um autenticador IEEE 802.1X compatvel, fornece um conjunto de portas de acesso


para que dispositivos de clientes sejam conectados. Tais portas podem ser reais (ex.
switch) ou logicas (ex. Access Point), e podem figurar em um de tres estados possveis:

Force Authorized : A porta esta liberada para qualquer conexao. Qualquer processo
de inicializacao de autenticacao pelo cliente e respondido com um pacote EAP-
Success;

Force Unauthorized : A porta se encontra desativada (via software), descartando


todo e qualquer dado transmitido para ela e transmitindo um pacote EAP-Failure
a toda tentativa de autenticacao;

Auto: O estado da porta, que se encontra inicialmente bloqueada, e definido pelo


resultado do processo de autenticacao.

O processo de autenticacao IEEE 802.1X se inicializa por meio do suplicante ou auten-


ticador. A ordem e determinada por qual PAE se torna ciente da conexao primeiro. Caso
o PAE suplicante tome a iniciativa, ele envia um pacote EAP-Start para tornar o auten-
ticador ciente da sua existencia. Caso contrario ou apos receber o pacote EAP-Start, o
PAE autenticador envia um solicitacao no formato EAP-Request ao suplicante que devera
responder com um EAP-Response contendo o nome do usuario ou dispositivo.
O autenticador neste momento retransmite o pacote EAP-Response do suplicante ao
servidor de autenticacao utilizando as camadas superiores do modelo TCP/IP de acordo
com a implementacao do servidor.
A qualquer instante o suplicante podera transmitir um pacote EAPOL-Logoff para
desautenticar a porta na qual se encontra conectado. O uso desta mensagem e recomen-
dado em sistemas multiusuario que se utiliza das credenciais do usuario para realizar a
autenticacao. O processo tambem podera ser interrompido caso os PAEs reconhecem que
foram desconectados (fsico ou logico).

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.

2.6 Servidores de Autenticacao


Servidores de autenticacao sao na sua maioria estruturados dentro de uma arquitetura
de Autenticacao, Autorizacao e Contabilidade (AAA - Authentication, Authorization, Ac-
counting), como apontado por Lopez et alii [2007]. Cada componente pode ser implemen-
tado de forma independente ou agregado aos servicos de outros servidores, cuja execucao
e transparente aos usuarios. Os objetivos de cada componente sao [Laat et al., 2000]:
Autenticacao: Servico responsavel por realizar a identificacao e autenticacao de
usuarios e/ou dispositivos. Quando atribudo ao uso de NAC, esta verificacao e
realizada antes que o cliente ingresse na rede local;

15
Autorizacao: Servico que de acordo com a identidade do usuario e/ou dispositivo
determina as permissoes e restricoes de um novo ingressante;

Contabilidade: Servico que registra a atividade do usuario, por exemplo, quais


dispositivos ele usou e por quanto tempo.

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].

2.6.1 Protocolo RADIUS


O protocolo RADIUS e amplamente empregado no mercado, dentro de um modelo
cliente/servidor, como uma solucao de interconexao entre servidores de autenticacao dife-
rentes, a partir de uma base de autenticacao centralizado de usuarios, cessao de direitos de
acesso ao meio e servicos, alem de registrar as atividades dos usuarios [Cisco-Systems, 2006].
Neste processo, o lado cliente e representado por um equipamento responsavel pelo
repasse de informacoes de usuarios, denominado de Network Access Server - NAS (ex.
switch), ao servidor RADIUS que age de acordo com as repostas fornecidas. Toda a co-
municacao e encapsulada dentro do campo de dados do protocolo User Datagram Protocol
(UDP) [Rigney et al., 2000].
Algumas informacoes transmitidas que sao sensveis a atividades maliciosas (ex. senha)
sao criptografadas por meio do algoritmo MD5 em conjunto com uma chave compartilhada
entre o cliente e o servidor. Alem disso, o RADIUS prove a possibilidade de trabalhar
com outros procotolos de seguranca como o EAP e prover mecanismos de seguranca mais
seguros. Na figura 2.9 e apresentada a area de atuacao do protocolo RADIUS em conjunto
com o padrao IEEE 802.1X.

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].

a) Formato dos Pacotes

Pacotes do protocolo RADIUS sao transmitidos contendo cinco campos com as se-
guintes funcoes (veja figura 2.10):

Figura 2.10: A estrutura de um pacote do protocolo RADIUS

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;

Identificacao: Campo contendo tambem oito bits. Responsavel por auxiliar na


identificacao de pacotes pertinentes a um determinado processo de autenticacao,
em conjunto com o endereco IP e a porta UDP de origem utilizada pelo cliente;

Tamanho: Campo de 16 bits destinados para determinar o tamanho total do pacote,


sendo de tamanho mnimo 20 e maximo 4096, em octetos;

Autenticador: Campo de 16 octetos utilizado para validar as respostas do servidor


RADIUS:

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;

Atributos: Campo de tamanho variavel que armazena dados especficos do processo


de autenticacao, autorizacao e detalhes de configuracao da solicitacao em anda-
mento.

b) Autenticacao

O processo de autenticacao, semelhante ao do EAP e 802.1X, inicia quando um NAS


transmite uma mensagem RADIUS do tipo Access-Request contendo credenciais e in-
formacoes que identificam o tipo de conexao solicitada ao servidor que ira determinar se
o acesso a rede sera concedido ou nao.
Apos a avaliacao inicial, o servidor podera solicitar maiores informacoes ao cliente via
mensagens do tipo Access-Challenge, cujo conteudo e resposta aguardado pelo servidor sao
definidos pelos protocolos de autenticacao utilizados e polticas de seguranca existentes.
O NAS, caso reconheca a solicitacao, responde a esta mensagem com outro pacote Access-
Request. Esta troca de mensagens ocorre ate que o NAS nao saiba responder (ex. nao
reconhece o protocolo de autenticacao), tendo a sua solicitacao rejeitada, ou o servidor
possui informacoes suficientes para decidir se deve conceder ou nao o acesso.
Caso a conexao seja rejeitada, uma mensagem Access-Reject e transmitida ao NAS,
sem necessariamente citar as razoes. No evento de ser aprovada, uma mensagem Access-
Accept e transmitida podendo conter instrucoes que devem ser respeitadas pelo NAS
quanto ao uso da conexao (ex. promover controle de banda).
Na situacao em que o NAS nao receba uma resposta do servidor dentro de um prazo
de tempo razoavel, ele podera retransmitir a sua ultima mensagem ou iniciar um novo
processo de autenticacao. Por definicao do protocolo, todos os resultados e informacoes
sobre as conexoes sao registrados no servidor para fins de contabilidade.
A figura 2.11 representa as mensagens trocadas entre um NAS e um servidor RADIUS,
segundo o processo de autenticacao definido pelo padrao IEEE 802.1X.

18
Figura 2.11: Comunicacao entre um NAS e um servidor RADIUS segundo o padrao IEEE
802.1X.

c) Atributos

O campo de atributos do protocolo RADIUS e subdividido em tres componentes


comuns sendo, o numero de identificacao do tipo do atributo (ID), tamanho e valor.
O componente tamanho indica o final do atributo utilizado. A estrutura dos valores
dependem do atributo sendo transmitido [Rigney et al., 2000].
Os NAS frequentemente fornecem dados complementares para que possam ser utiliza-
dos nos criterios de concessao de acesso do servidor, como exemplo pode-se citar em qual
porta fsica o dispositivo do usuario esta conectado. Uma lista de atributos utilizados
para prover autenticacao e outras informacoes sao apresentados na tabela 2.6.1 a seguir:

Tabela 2.2: Lista de atributos RADIUS

Nome ID Tipo Descricao


User-Name 1 Atributo que contem o nome do usuario sendo au-
tenticado.

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.

2.6.3 Active Directory


AD e um servico de diretorio disponvel em sistemas operacionais voltados as ativi-
dades de servidores da empresa Microsoft Corporation, o Windows Server 2003 e 2008.
Por ser um servico de diretorio, o AD trabalha como uma base de dados unificada de
informacoes de usuarios (ex. senha), dispositivos e servicos. Todas as informacoes sao
organizadas dentro uma estrutura global, denominada arvore organizacional, que pode
ser subdivida em domnios (ex. departamentos ou filiais de uma empresa). Integrado ao
AD tem-se um servidor Domain Name System (DNS) que mantem registros dos nomes e
enderecos IPs de todis os dispositivos do domnio de forma a facilitar o acesso aos servicos
existentes [Tulluch, 2007].
As permissoes e restricoes de todos usuarios cadastrados no servidor sao definidas de
acordo com o grupo, prevalecendo as permissoes mais favoraveis, alem da implementacao
de diretivas de seguranca [Shapiro e Boyce, 2006].
As diretivas definem os criterios que devem ser respeitados pelos usuarios e/ou dispo-
sitivos aos quais eles sao aplicados. Tais criterios podem citar que determinados servicos
sejam executados, que usuarios de determinados grupos podem ou nao autenticar no
dispositivo, a complexidade da senha do usuario, dentre outros elementos. Durante o
processo de autenticacao de usuarios, por meio do protocolo Kerberos versao 5, disposi-
tivos integradas ao AD consultam o servidor para determinar quais diretivas devem ser
aplicadas [Hassell, 2006].
Apesar de nao prover suporte direto a padroes NAC (ex. IEEE 802.1X), um servidor
AD e capaz de operar como uma base centralizada de autenticacao para servicos que
reconhecem o protocolo Kerberos, inclusive um servidor RADIUS [Dias, 2002].

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.

Tabela 2.3: Lista de atributos RADIUS utilizados para implementar VLANs

Nome ID Tipo Descricao


Tunnel-Type 64 Indica o protocolo de tunelamento sendo uti-
lizado. No uso do padrao IEEE 802.1Q este
atributo possui o valor 13 que representa o
uso de VLAN.
Tunnel-Medium-Type 65 Aponta a tecnologia de propagacao do meio
para utilizar um protocolo de tunelamento.
O valor 6 indica o uso de redes segundo os
padroes 802 da IEEE.

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.

2.8 Resumo do Captulo


Neste captulo foi apresentado como um invasor pode afetar a operacao de uma rede
comprometendo servidores, dispositivos de clientes e equipamentos de comutacao de da-
dos. Como solucao ao problema de interceptacao, diversas tecnicas de criptografia foram
descritas em conjunto com uma arquitetura generica de autenticacao, o protocolo EAP.
Baseando-se no uso do EAP, uma segunda solucao, que visa identificar invasores por
meio de controle de acesso a rede, e proposta utilizando-se o padrao IEEE 802.1X em
conjunto com o protocolo RADIUS. Como extensao a capacidade de avaliacao do servidor
RADIUS, e apresentada a tecnologia NAP apta a consultar o estado de execucao dos
dispositivos clientes quanto a criterios de seguranca. Por ultimo, a tecnologia de servidor
AD e suas capacidades sao mencionadas.

23
Captulo 3

Ambiente de Implementacao

Este captulo apresenta a estrutura fsica, servicos de rede e problemas de segu-


ranca do campus da Universidade Federal de Goias localizada na cidade de Catalao/GO
(CAC/UFG). O ambiente do campus, de acordo com suas caractersticas, sera objeto de
implementacao do projeto de NAC, por meio das tecnologias apresentadas no captulo an-
terior. As informacoes sobre a rede do campus foram levantadas em 11 de maio de 2010, ce-
didas pelo o Centro de Recursos Computacionais (CERCOMP-Catalao). O CERCOMP-
Catalao e responsavel pela administracao, implementacao e manutencao dos servicos de
rede, equipamentos e estacoes de trabalho do campus.

3.1 Estrutura Fsica


A estrutura do campus em 2010 atende aproximadamente 2800 alunos, 280 professores
e 70 tecnicos administrativos, alem disto a estrutura de rede prove servicos a 620 com-
putadores, parcialmente alocados em 10 laboratorios de informatica, alem de maquinas
pessoais. Os equipamentos estao distribudos em 18 predios e mais 6 salas (alugadas)
num edifcio proximo - aproximadamente 50 metros da area institucional, apresentados
na figura 3.1, com os seguintes nomes e atividades desenvolvidas em suas dependencias:

Blocos A-K: Visam agrupar as coordenacoes, salas de professores e laboratorios de


todos os cursos;

DAA: Predio que contem o Diretorio de Assuntos Academicos do campus;

Bloco de Laboratorios: Destinado para as coordenacoes e laboratorios dos cursos de


Fsica e Qumica;

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;

Auditorio: Como o nome indica, contem um auditorio com saguao de entrada e


diversas salas para atender eventos e outras atividades realizadas na universidade;

Centro de Telefonia e Informatica (CTI): Localizacao do CERCOMP-Catalao e o


nucleo da rede.

Figura 3.1: Desenho da localizacao dos edifcios.

Dentro dos predios do CAC/UFG a comunicacao de rede e fornecida atraves do uso


de cabos do tipo Unshielded Twisted Pair (UTP), categoria 5e. A disponibilizacao dos
pontos de rede encontra-se nas paredes de cada sala. Todos os pontos sao conectados
a um rack central de cada bloco (ou par de blocos,) com excecao dos laboratorios de
informatica que possuem um rack aereo (fixado na parede acima do piso) para atender a
maior quantidade de dispositivos no local. Em algumas localidades APs estao conectados
a um ponto de rede ou diretamente no rack central e provem acesso sem fio a usuarios
detentores de sua chave de criptografia.
Com uma infraestrutura de topologia em estrela, toda a comunicacao entre os blocos
ocorre via fibra optica, de 1-Gbps, entre os racks centrais e o nucleo da rede localizado
no CTI conforme apresentado na figura 3.2.
Entre as salas alugadas e o campus, a transmissao e atraves de sinal sem-fio com
uma rede para prover comunicacao com o rack central do predio, e mais tres redes para
interconectar os usuarios com o rack.

25
Figura 3.2: Conexoes dos racks centrais com o nucleo de rede numa topologia em estrela.

3.1.1 Equipamentos de Rede


Entre switches a transmissao de pacotes dentro da rede cabeada e realizada com
conexoes de 1-Gbps. Pelas caractersticas da topologia em estrela, um dos switches recebe
as conexoes de todos os outros. Este equipamento, denominado de backbone, trabalha
na terceira camada do modelo de rede TCP/IP e localiza-se dentro do CTI. Do backbone
saem conexoes para roteadores e gateways, os quais regulam o acesso aos servicos de rede
e a Internet. Distribudos em todo o campus se encontram 38 switches, sendo que alguns
possuem suporte as tecnologias IEEE 802.1X, 802.1Q e RADIUS, e outros nao possuem
suporte conforme a lista a seguir:

13 nao sao gerenciaveis e portanto nao possuem suporte as tecnologias descritas;

O CERCOMP-Catalao preve a troca destes equipamentos por versoes gerencia-


veis ate o final de junho de 2010;

25 sao gerenciaveis e aptos a trabalharem com as tecnologias propostas;

2 sao da marca 3COM sendo que um deles e o equipamento backbone, de


modelo 4200G, e o segundo do modelo 2226 Plus;
21 sao da marca Allied Telesis do modelo FS750-24POE;
2 da marca Edge-Core, modelo ES3528M.

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;

1 da marca Linksys do modelo WAP54G;

2 da marca 3COM do modelo 7760 11a/b/g POE;

Prove suporte a IEEE 802.1Q;

3 da marca AP Router do modelo WR254;

2 da marca RouterBoard, modelo RB493;

Fornece suporte a IEEE 802.1Q.

3.1.2 Sistemas Operacionais


Por poltica do CERCOMP-Catalao, as estacoes de trabalho sao incentivadas a possu-
rem um dos seguintes sistemas operacionais: Microsoft Windows XP (com service pack
3), Vista, 7 ou Linux da distribuicao Ubuntu (9.04 ou mais recente). Todos estes sistemas
operacionais preveem suporte a tecnologia IEEE 802.1X. O suporte as polticas de acesso
de um servidor NAP e apenas fornecido nas maquinas com Windows.

3.2 Servicos de Rede


Os servicos de rede da CAC/UFG sao divididos em dois grupos denominados de in-
ternos e publicos. O grupo interno prove servicos restritos para uso somente dentro da
rede do campus, enquanto os publicos visam atender usuarios dentro e fora da instituicao.
Contudo, sendo o projeto de implementacao de NAC destinado ao uso interno, todos
servicos descritos na tabela 3.1 atendem aos dois grupos.

Tabela 3.1: Lista dos servicos de rede do CAC/UFG

Servico de Rede Descricao


Utilizando o Dynamic Host Configuration Protocol
Alocacao Dinamica de En-
(DHCP), este servico de rede visa alocar enderecos
dereco IP
IP com sua respectiva mascara, endereco do gateway
e de servidores de DNS, para as maquinas ingressan-
tes na rede.

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.

3.3 Problemas de Seguranca


Em decorrencia da estrutura atual de rede do campus, situacoes de ameaca aos ser-
vidores e equipamentos sao difceis de combater de forma ativa. Relatos de usuarios
realizando ataques de Denial of Service (DoS) nao sao desconhecidos, e tais ataques so-
brecarregam a capacidade de operacao dos switches, roteadores e servidores provocando
queda de conectividade de rede em setores ou todo o campus. Frequentemente possuindo
apenas o endereco IP do agressor, o CERCOMP-Catalao se encontra incapaz de identificar
o indivduo sem uma exaustiva busca por eliminacao dos blocos, racks, switches, porta e
sala durante um ataque. As solucoes mais comuns sao reativas e baseadas no controle de
banda de possveis locais de origem (ex. laboratorios de informatica) e regras de firewall
nos roteadores.
Um segundo problema deparado e ocorrencia de equipamentos nao regulamentados
pelo CERCOMP-Catalao, como APs, sendo conectados a rede. Utilizando-se de um meio
de propagacao aberto (o ar), um AP e capaz de conceder acesso a usuarios, autorizados
ou nao, fora das dependencias da universidade diretamente para a rede interna. Tais
conexoes podem se tornar propcias a ocorrencia de ataques, citados anteriormente, com
a identificacao e punicao do(s) agressor(es) somente por meio de intervencao judicial.
A proliferacao de programas maliciosos via rede local, internet e mdias removveis e

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.

3.4 Resumo do Captulo


Neste captulo diversas caractersicas da rede do campus foram apresentadas como, a
topologia da infraestrutura, a lista de servicos de rede e o suporte dos equipamentos seus
sistemas operacionais com enfase ao suporte as tecnologias de autenticacao em nvel de
porta. Todo analise apresentado neste captulo fundamenta a implementacao discutido
no proximo captulo.

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.

Figura 4.1: Locais de atuacao das tecnologias utilizadas pelo projeto.

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:

Clientes com suporte a NAP e respeitam as polticas de seguranca;

Clientes com suporte a NAP, mas nao conforme as polticas de seguranca;

Clientes sem suporte a NAP.

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.

4.2 Implementacao dos Servidores


A solucao RADIUS adotada foi o Network Policy Server (NPS) que possui integracao
nativa com NAP e AD. O NPS e um servidor desenvolvido exclusivamente para o sistema
operacional Windows Server 2008, portanto a sua instalacao deve ser obrigatoriamente
realizada nas edicoes existentes do sistema (ex. R2 Standard, Enterprise e Datacenter ). A
edicao adotada pelo projeto foi a R2 Standard para dispositivos de arquitetura de 64bits.
A maquina hospedeira (host) do servidor foi adicionada ao domnio do servidor AD,
desta forma, todas as credenciancias fornecidas ao NPS serao avaliadas na base centrali-
zada de contas de usuarios do CAC/UFG. Para prover suporte a tecnica de criptografia

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].

4.3 Configuracao dos Servidores


O NPS divide sua configuracao em tres categorias de polticas que podem ser acessadas
pelo painel de gerenciamento do servidor:

Polticas de Requisicao de Acesso: Definem as condicoes e regras de auten-


ticacao globais alem de possibilitar o redirecionamento para outro servidor RADIUS;

Polticas de Saude: Definem como os resultados do servidor HRA serao tratados;

Polticas de Rede: As condicoes e regras que devem ser respeitadas para ter o
acesso aprovado.

Para o projeto proposto, somente e necessaria uma unica Poltica de Requisicao


de Acesso para tratar conexoes oriundas de clientes RADIUS, cadastrados no servidor
NPS. A poltica tambem foi configurada para aceitar os metodos de criptografia PEAP
e baseadas em certificados, demonstrado na figura 4.2. Suporte ao PEAP-MSCHAPv2 e
definido durante a adicao do PEAP a lista de metodos aceitos.

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.

Figura 4.4: Localizacao da opcao para abrir o gerenciador de redes.

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.

4.6 Resumo do Captulo


Com a implementacao do projeto, os servidores de autenticacao sao capazes de for-
necerem ao CERCOMP-Catalao informacoes relativas a localizacao de todos os usuarios
que fizeram uso da rede. Estas informacoes podem ser entao utilizadas na identificacao
de possveis agressores.
Ha ainda a identificacao de quais dispositivos necessitam de programas e atualizacoes
de seguranca, para que medidas de prevencao e contencao de ameacas digitais possam ser
aplicadas diretamente sobre a fonte delas na rede. A alocacao numa rede de remediacao
concede tempo ao CERCOMP-Catalao para lidar com tais problemas ao minimizar a
propagacao destas ameacas para dispositivos na VLAN 2, dita segura, alem de incentivar
usuarios a observarem melhor os criterios de seguranca.
Quanto aos equipamentos de rede, a configuracao proposta preve uma reducao ou
eliminacao completa do uso de equipamentos nao regulamentados conectados a infraes-
trutura, pela incapacidade destes dispositivos de proverem acesso e/ou atenticacao.

37
Captulo 5

Testes

Para avaliar a capacidade do servidor RADIUS e a base de usuarios, por meio do


servidor AD, em atender solicitacoes de autenticacao, testes de carga foram elaborados e
executados. A descricao dos testes, suas metricas e os resultados encontrados sao apre-
sentados neste captulo.

5.1 Teste de Carga


Testes de carga sao projetados para simular situacoes reais que podem ocorrer apos
um servidor (ou aplicacao) ser posto em producao. Tais testes apontam falhas, possveis
gargalhos de execucao e determinam o tempo de resposta de servidores, dentre outros
objetivos [Segue-Software, 2005].
O servidor RADIUS proposto, apesar de ser destinado as maquinas do campus, devera
ser capaz de lidar com situacoes extremas oriundas de ataques ou possivelmente equipa-
mentos defeituosos, alem da expansao contnua da unidade academica. Ainda mais, o
servidor de domnio devera ser capaz de lidar com tais situacoes e fornecer, de forma
interrupta, confirmacoes das credenciais fornecidas para autenticacao.
Para esta finalidade tres conjuntos de testes foram elaborados e executados utilizando
10, 20 e 30 maquinas. Cada maquina realizou 200 tentativas de autenticacao simultane-
amente ate atingir um total de 15.000 solicitacoes. Ou seja, os servidores foram sujeitos
a 2.000, 4.000 e 6.000 processos de autenticacao simultaneamente e um total de 150.000,
300.000 e 450.000 respectivamente.

5.2 Metricas de Avaliacao


Os resultados dos testes foram avaliados de acordo com as seguintes metricas:

Tempo medio de resposta;

38
Quantidade media de falhas de autenticacao, caso haja;

Consumo de processador, memoria, conexao de rede e espaco de disco do servidor


RADIUS;

Consumo de processador e memoria do servidor de domnio.

Todas as tentativas de autenticacao foram baseadas em credenciais validas e projetadas


para serem avaliadas por todas as polticas de rede, porem aprovada somente pela ultima
destinada a clientes sem suporte ao NAP. O servidor RADIUS armazenara toda e qualquer
tentativa de autenticacao em disco.
O valor das metricas avaliadas dos servidores foram consultadas via o uso do protocolo
Simple Network Management Protocol (SNMP) por uma maquina remota em intervalos
de tempo de cinco minutos. O valor respectivo de cada intervalo e referente a media
durante o perodo.

5.3 Recursos dos Servidores


O servidor RADIUS, configurado segundo o projeto de implementacao, se encontra
numa maquina com os seguintes recursos a sua disposicao: 768MB de memoria, proces-
sador Intel Dual Core de 3.0GHZ e um particao de disco de 30GB. O servidor de domnio
conta com o acesso a 1GB de memoria e um processador Intel Dual Core 1,87GHZ. Ambos
estao conectados a rede num conexao de 1Gbps.

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.

Atingindo um pco maximo de 4,4Mbps de trafego de rede durante a realizacao dos


testes, o servidor RADIUS se apresentarar incapaz de lidar com requisicoes, por conta do
recurso de processamento, muito antes de atingir seu limite de conexao.
A variacao de consumo de memoria durante a realizacao dos testes, entre 1 a 5MB, e
negligenciavel diante da quantidade disponibilizada.

40
Captulo 6

Conclusoes Finais

O presente trabalho buscou apresentar os pontos, dentro de uma modelo cliente/servidor,


em que um invasor poderia comprometer um rede de computadores. Estes pontos localizam-
se nos servidores, na infraestrutura e nos dispositivos dos clientes. Os servidores, para
gerenciar as permissoes de usuarios, fazem uso de autenticacao em conjunto com tecnias
de criptografia que impedem a interceptacao de dados sigilosos. Diversas tecnicas de
criptografia foram apresentadas, as quais tambem possam ser aplicadas em conjunto com
tecnologias de controle de acesso a rede (NAC). Tais tecnologias visam controlar e con-
tabilizar o ingresso de usuarios numa rede, isolando os dispositivos dos usuarios ate que
credenciais validas sejam fornecidas. Em redes LANs e WANs faz-se uso do padrao IEEE
802.1X em conjunto com um servidor de autenticacao, que pode ser implementado com
o protocolo RADIUS, capaz de avaliar credenciais de usuarios em conjunto com outros
criterios (ex. horario e local). Um servidor RADIUS trabalhando em conjunto com um
servidor NAP e apto a identificar quais dispositivos de clientes sao vulneraveis a programas
maliciosos e invasores. Dispositivos vulneraveis podem ser entao isolados numa subrede,
via o uso de VLANs segundo o IEEE 802.1Q, minimizando o risco a outros dispositivos.
Visando aplicar uma solucao NAC para a rede do campus Catalao da Universidade
Federal de Goias e minimizar os problemas encontrados, um projeto de implementacao foi
apresentado utilizando as tecnologias citadas anteriormente. O resultado do projeto e um
servico de autenticacao apto a armazenar e fornecer informacoes relativas a localizacao
de todos os usuarios que fizeram uso da rede, inclusive de invasores.
Dispositivos que necessitam de programas e atualizacoes de seguranca sao alocados
numa VLAN de remediacao que concede acesso somente a servicos essenciais para a
resolucao dos problemas encontrados, reduzindo a propagacao de ameacas digitais. O
controle de acesso e realizado em nvel de porta por equipamentos de redes com suporte
as tecnologias abordadas, negando acesso a outros equipamentos que nao sejam regula-
mentados pelo CERCOMP-Catalao.
Testes de carga realizados no servidor RADIUS e na base centralizada de contas de

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.

6.1 Trabalhos Futuros


O uso de IEEE 802.1Q pelo projeto proposto abre caminho para trabalhos futuros
destinados a segmentacao total dos departamentos da CAC/UFG em VLANS distintas e
isoladas, reduzindo ainda mais a ocorrencia de riscos de seguranca.
Regras mais especficas podem ser elaboradas no servidor RADIUS de forma a conceder
acesso a professores e tecnicos em suas respectivas VLANS independente da localizacao
no campus, alem de levarem em consideracao o acesso de alunos de acordo o local, horario
e equipamento.
Tais trabalhos deverao gerar uma quantidade consideravel de regras de acesso, mere-
cendo atencao quanto aos recursos de processamento dos servidores. Assim sendo, o tema
clusterizacao deve ser analisado como uma alternativa viavel de implementacao.
Para conceder a capacidade ao servidor NAP de avaliar computadores com Linux de
forma gratuita, e sugerido como trabalho futuro um estudo sobre a viabilidade e possvel
implementacao de um cliente NAP para este sistema operacional.
Para ampliar o nvel de seguranca e sugerido a elaboracao de um projeto para a
geracao de certificados para determinados usuarios. Podendo ser inicialmente destinado
aos administradores de rede, o uso de certificados descartara a necessidade de sempre
exigir a digitacao de credenciais por usuarios ao usarem suas maquinas de uso particular,
nao integradas ao domnio, sem afetar as polticas de seguranca.

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.

ADOBA, B. et al. Extensible Authentication Protocol (EAP). Internet Engineering Task


Force RFC 3748. 2004.

ALLIED-TELESIS. 802.1x White Paper. Bothell, WA, USA: Allied Telesis, Inc. 2006.

BORISOV, N.; GOLDBERG, I.; WAGNER, D. Intercepting mobile communications: The


insecurity of 802.11. 2001.

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.

FUNK, P.; BLAKE-WILSON, S. Extensible Authentication Protocol Tunneled Transport


Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0). Internet Engineering
Task Force RFC 5281. 2008.

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.

IEEE-COMPUTER-SOCIETY. Virtual Bridged Local Area Networks: IEEE Std 802.1Q-


2005. Institute of Electrical and Electronics Engineers Standard for Local and Metropo-
litan Area Networks. 2006.

IETF. Diameter Maintenance and Extensions (dime) - Working Group. Disponvel em:
<http://datatracker.ietf.org/wg/dime/charter/>. Acesso em 10 de abr. 2010.

JONSSON, J. On the Security of CTR + CBC-MAC: NIST Modes of Operation - Addi-


tional CCM Documentation. Proceedings from Selected Areas of Cryptography. 2002.

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.

PALEKAR, A. et al. Protected EAP Protocol (PEAP) Version 2. 2004.

POTTER, B. Conversing wired and wireless authentication. 2007. Network Security Vo-
lume 2007, Issue 10, p. 18-20, Editora Elsevier Ltd.

RIGNEY, C. et al. Remote Authentication Dial In User Service (RADIUS). Internet


Engineering Task Force RFC 2865. 2000.

ROMEIRO, C. A. Estudo do Protocolo RADIUS: Remote Authentication Dial-in User


Service. Monografia (Graduacao) - Catalao, GO: Universidade Federal de Goias, 2003.
Trabalho de conclusao do curso de bacharelado de ciencia da computacao.

SEGUE-SOFTWARE. Choosing A Load Testing Strategy: Why and How to Optimize


Application Performance. Lexington, MA, USA: Segue Software, Inc. 2005.

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.

ZAPATER, M.; SUZUKI, R. Seguranca da informacao: Um diferencial determinante na


competitividade das corporacoes. Promon S.A., 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