Implementa˘c~ao de 802.1X e RADIUS Integrado ao Active ... · S. Ulh^oa, Rafael Implementa˘c~ao...

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 aoActive 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 tıtulo 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


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


Network Access Protection no CAC/UFG

Monografia apresentada e aprovada em de

Pela Banca Examinadora constituıda 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 polıticas de acesso e seguranca numa rede torna possıvel aos administradores

regulamentar o uso da infraestrutura e minimizar brechas de segurancas em dispostivos

de usuarios. Tais polıticas 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 Capıtulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3 Ambiente de Implementacao 24

3.1 Estrutura Fısica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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


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


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 edifıcios. . . . . . . . . . . . . . . . . . . . . . 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

Capıtulo 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 capıtulo 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 caracterısticas da rede interna do campus sao citadas no capıtulo 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 capıtulo 4.

Para avaliar a capacidade de operacao dos servidores de autenticacao utilizados pelo

projeto, conjuntos de testes foram realizados e descritos no capıtulo 5, junto com os

resultados obtidos. Por fim, no capıtulo 6 sao apresentadas as conclusoes do trabalho.

1

Capıtulo 2

Estado da Arte

Neste capıtulo 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 possuıa 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 princıpio, 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 fısicos ou logicos, ou seja,

tornar todos os programas, equipamentos e dados ao alcance de todas os dispositivos

na rede, independente da localizacao fısica 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 possıvel 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

irreconhecıveis 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 disponıvel 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 antivırus, 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 Polıticas 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 polıticas [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 saıda. 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 saıda 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 saıda (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 possıvel 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 perıodo. 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-

terıstica 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 Constituıdo 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-

ged)

Contendo ID 3, seu uso e indicado quando o cliente

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

(LEAP)

Possuindo ID 17, o LEAP e uma tecnica proprietaria de-

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 susceptıvel

a ataques por dicionario ao expor as senhas, em seu for-

mato criptografado, durante o processo de autenticacao.

EAP com Tunneled

TLS (EAP-TTLS)

De ID 21, EAP-TTLS estabelece uma conexao segura

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

(PEAP)

Identificado pelo ID 25, o PEAP opera de forma seme-

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 polıticas

de seguranca vigentes na rede como, por exemplo, a existencia de uma programa antivırus

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 nıvel 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 possıveis 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 compatıvel, 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 possıveis:

• 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 (fısico ou logico).

14

No caso em que o suplicante nao receba nenhuma resposta de um possıvel autenticador,

dentro de um perıodo 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 susceptıveis 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 atribuıdo 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 sensıveis 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 benefıcios que se tornarao possıveis 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 mınimo 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 constituıdo por um valor aleatorio,

imprevisıvel 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 constituıdo 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 especıficos 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 polıticas 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 fısica 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


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 fısica 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 especıficos

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 fısico

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 atribuıdo 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 antivırus 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 disponıvel 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 domınios (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 domınio 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 fısica, 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 polıticas 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 fısica.

Tabela 2.3: Lista de atributos RADIUS utilizados para implementar VLANs


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


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 Capıtulo

Neste capıtulo 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

Capıtulo 3

Ambiente de Implementacao

Este capıtulo apresenta a estrutura fısica, 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 caracterısticas, sera objeto de

implementacao do projeto de NAC, por meio das tecnologias apresentadas no capıtulo 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 Fısica

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 distribuıdos em 18 predios e mais 6 salas (alugadas)

num edifıcio 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

Fısica e Quımica;

• 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 edifıcio;

• 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 edifıcios.

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 caracterısticas 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. Distribuıdos 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 polıtica 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 polıticas 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

Alocacao Dinamica de En-

dereco IP

Utilizando o Dynamic Host Configuration Protocol

(DHCP), este servico de rede visa alocar enderecos

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

(DNS)

Servico de traducao de nomes por enderecos IP.

Servidor de Arquivos Prove o armazenamento de programas, documen-

tos e outros arquivos de uso comum da comunidade

academica.

Servidor de Instant Messa-

ging (IM)

Atende programas de mensagens instantaneas de uso

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

(FTP)

Servico de transmissao remota de arquivos, usado

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 capıtulo

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 capıtulo 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 difıceis 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 indivıduo 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 possıveis 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 propıcias 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 mıdias removıveis 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 capıtulo 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 susceptıvel

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 crıtico 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.


Neste capıtulo diversas caracterısicas 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 nıvel de

porta. Todo analise apresentado neste capıtulo fundamenta a implementacao discutido

no proximo capıtulo.

30

Capıtulo 4

Implementacao

Apos citar diversas tecnologias para prover controle de acesso a rede e apresentar a

estrutura de rede do CAC/UFG, neste capıtulo 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 domınio 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 polıticas de seguranca NAP e responsavel por verificar se o dispositivo

solicitando acesso a rede possui antivırus instalado e atualizado, firewall habilitado e

todas as atualizacoes crıticas 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 possıveis:

VLAN 2 e 3. A VLAN 2 e destinada a dispositivos aprovados pelas polıticas 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 capıtulo 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 polıticas de seguranca;

• Clientes com suporte a NAP, mas nao conforme as polıticas 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 domınio 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 domınio.

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 polıticas que podem ser acessadas

pelo painel de gerenciamento do servidor:

• Polıticas de Requisicao de Acesso: Definem as condicoes e regras de auten-

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

• Polıticas de Saude : Definem como os resultados do servidor HRA serao tratados;

• Polıticas de Rede : As condicoes e regras que devem ser respeitadas para ter o

acesso aprovado.

Para o projeto proposto, somente e necessaria uma unica Polıtica de Requisicao

de Acesso para tratar conexoes oriundas de clientes RADIUS, cadastrados no servidor

NPS. A polıtica 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 Polıticas 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 polıtica(s) do HRA. Quanto a lista de elementos que o servidor HRA devera avaliar,

estes foram definidos junto aos criterios de polıticas para dispositivos com Windows,

encontrado via a navegacao na arvore do painel do servidor.

Baseando-se no significado das Polıticas de Saude , as Polıticas de Rede foram

criadas segundo as tres regras definidas pelo projeto. Alem disso, cada polıtica 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 capıtulo 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 capıtulo 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 capıtulo 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 domınio, 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 domınio, 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 polıticas de seguranca do NAP,

um aviso tambem sera exibido alertando o usuario sobre os problemas encontrados que

nao foram possıveis 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.


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 possıveis 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

Capıtulo 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 capıtulo.

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, possıveis

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 contınua da unidade academica. Ainda mais, o

servidor de domınio 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 domınio.

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

para serem avaliadas por todas as polıticas 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 perıodo.

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 domınio

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 possıvel afirmar que o recurso mais crıtico

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 domınio 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 pıco 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

Capıtulo 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 nıvel 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 especıficas 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 possıvel

implementacao de um cliente NAP para este sistema operacional.

Para ampliar o nıvel 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 domınio, sem afetar as polıticas 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


HASSELL, J. Learning Windows Server 2003. 2nd. edicao. ed. Sebastopol, CA, USA:

Editora O’Reilly, 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. Disponıvel 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


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

Implementa˘c~ao de 802.1X e RADIUS Integrado ao Active ... · S. Ulh^oa, Rafael Implementa˘c~ao...

Documents

Transcript of Implementa˘c~ao de 802.1X e RADIUS Integrado ao Active ... · S. Ulh^oa, Rafael Implementa˘c~ao...