Eduroam: Acesso Sem Fio Seguro para Comunidade Acadêmica Federada

Eduroam
Acesso sem fio seguro para Comunidade Acadmica Federada

Dbora C. Muchaluat Saade Ricardo Campanha Carrano Edelberto Franco Silva
Colaborador
Luiz Claudio Schara Magalhes
A RNP Rede Nacional de Ensino e Pesquisa qualificada como uma Organizao Social (OS), sendo ligada ao Ministrio da Cincia, Tecnologia e Inovao (MCTI) e responsvel pelo Programa Interministerial RNP, que conta com a participao dos ministrios da Educao (MEC), da Sade (MS) e da Cultura (MinC). Pioneira no acesso Internet no Brasil, a RNP planeja e mantm a rede Ip, a rede ptica nacional acadmica de alto desempenho. Com Pontos de Presena nas 27 unidades da federao, a rede tem mais de 800 instituies conectadas. So aproximadamente 3,5 milhes de usurios usufruindo de uma infraestrutura de redes avanadas para comunicao, computao e experimentao, que contribui para a integrao entre o sistema de Cincia e Tecnologia, Educao Superior, Sade e Cultura.
Ministrio da Cultura Ministrio da Sade Ministrio da Educao Ministrio da Cincia, Tecnologia e Inovao
Eduroam:
acesso sem fio seguro para Comunidade Acadmica Federada
Dbora C. Muchaluat Saade Ricardo Carrano Edelberto Franco Silva
Colaborador
Eduroam:
acesso sem fio seguro para Comunidade Acadmica Federada
Dbora C. Muchaluat Saade Ricardo Carrano Edelberto Franco Silva
Colaborador
Rio de Janeiro Escola Superior de Redes 2013
Copyright 2013 Rede Nacional de Ensino e Pesquisa RNP Rua Lauro Mller, 116 sala 1103 22290-906 Rio de Janeiro, RJ Diretor Geral
Nelson Simes
Diretor de Servios e Solues
Jos Luiz Ribeiro Filho
Escola Superior de Redes

Coordenao
Luiz Coelho
Edio
Pedro Sangirardi Lincoln da Mata

Coordenao Acadmica de Gesto de Identidade Reviso
Renato Duarte
Equipe ESR (em ordem alfabtica)
Celia Maciel, Cristiane Oliveira, Derlina Miranda, Edson Kowask, Elimria Barbosa, Lourdes Soncin, Luciana Batista, Luiz Carlos Lobato, Sergio Ricardo de Souza e Yve Abel Marcial.
Capa, projeto visual e diagramao
Tecnodesign
Verso
1.1.0
Este material didtico foi elaborado com fins educacionais. Solicitamos que qualquer erro encontrado ou dvida com relao ao material ou seu uso seja enviado para a equipe de elaborao de contedo da Escola Superior de Redes, no e-mail info@esr.rnp.br. A Rede Nacional de Ensino e Pesquisa e os autores no assumem qualquer responsabilidade por eventuais danos ou perdas, a pessoas ou bens, originados do uso deste material. As marcas registradas mencionadas neste material pertencem aos respectivos titulares. Distribuio
Rua Lauro Mller, 116 sala 1103 22290-906 Rio de Janeiro, RJ http://esr.rnp.br info@esr.rnp.br
Dados Internacionais de Catalogao na Publicao (CIP) S112e Saade, Dbora Cristina M. Eduroam: Acesso Sem Fio Seguro para Comunidade Acadmica Federada / Dbora C. Muchaluat Saade, Ricardo Carrano, Edelberto Franco Silva; Colaborador Luiz Claudio Schara Magalhes. Rio de Janeiro: RNP/ESR, 2013. 158 p. : il. ; 28 cm. Bibliografia: p. 143-144. ISBN 978-85-63630-25-4
1. Redes de Computadores Segurana. 2. Redes sem fio. 3. Autenticao. 4. Eduroam (education roaming). I. Carrano, Ricardo. II. Silva, Edelberto Franco. III. Ttulo. CDD 004.66
Sumrio
1. Viso geral do eduroam
Introduo1 O projeto eduroam-br3 Tecnologias utilizadas no eduroam3 RADIUS4 IEEE 802.11i4 IEEE 802.1X5 Arquitetura IEEE 802.1X5 Comunidade Acadmica Federada5 Funcionamento do eduroam6 Autenticao na instituio de origem7 Interconexo com Amrica Latina e Europa7
2. Redes sem fio IEEE 802.11

Introduo9 Redes IEEE 802.119 IEEE 802.11 e Wi-Fi10 IEEE 802.11 arquitetura e modos de operao10 Modos de operao: ad hoc10 Modos de operao: infraestruturado11 Componentes em redes ad hoc12 Componentes em redes infraestruturadas12 Arquitetura: Basic Service Set12 iii
Arquitetura: Independent BSS13 Arquitetura: infrastructure BSS13 Arquitetura: Extended Service Set14 Identificadores14 Fluxo de dados em um ESS14 SSID15 Sistemas de distribuio15 Conectando-se a uma rede sem fio16 Varredura Passiva e Ativa16 Beacons17 Recebendo beacons17 Varredura Passiva18 Mltiplos APs e ESSIDs18 Varredura Ativa19 Estados de uma estao19 Autenticao20 Associao20 Troca de mensagens para associao20 Depois da associao21 Reassociao21 Desassociao e Desautenticao22 Hand over22 IEEE 802.11 Camadas PHY e MAC22 Camada fsica (PHY)22 Canais na faixa de 2,4 GHz23 Canais na faixa de 5GHz24 Taxas do IEEE 802.1124 Camada MAC25 CSMA/CA26 O backoff exponencial26 O quadro 802.1127 Endereos MAC28 Endereo de destino28 Vazo efetiva das redes Wi-Fi29 iv
Segurana em redes IEEE 802.1130 O problema da segurana30 Problemas tpicos das redes sem fio30 Padres de segurana no Wi-Fi31 WEP32 WEP: cifragem32 WEP: integridade33 Problemas do WEP33 WPA 134 WPA 1: TKIP34 WPA 235 WPA: Personal versus Enterprise35 WPA Enterprise: esquema36 IEEE 802.1X e EAP36 Robust Security Network (RSN)37 Recomendaes de segurana37 Requisitos eduroam38 Atividade Prtica 1 Configurar AP para autenticar em servidor RADIUS38 Cadastrando o AP no servidor RADIUS38 Configurando roteador com DD-WRT39 Configurando o roteador sem fio Linksys WRT54G 41
3. Mtodos de autenticao
Introduo43 Autenticao em redes 802.1143 IEEE 802.11i44 IEEE 802.1X45 Arquitetura IEEE 802.1X45 O protocolo EAP46 Transao EAP47 Exemplo de transao EAP48 Mtodos EAP49 TLS (Transport Layer Security)50 TTLS e PEAP50 v
Mtodos de autenticao interna51 Password Authentication Protocol (PAP)51 Microsoft Challenge-Handshake Authentication Protocol (MSCHAP)52 PAP e MSCHAPv2 disponibilidade atual52 Outros mtodos (menos usados)53 Mtodos EAP e eduroam53 Atividade Prtica 2 Configurar clientes com diferentes mtodos de autenticao54 Configurao de dispositivos para TTLS/PAP54 Configuraes para Android54 Configuraes para Windows55 Configuraes para Linux (Ubuntu)57 Configurao de dispositivos para PEAP/MSCHAPv258 Configuraes para Android58 Configuraes para Windows XP59
4. RADIUS Viso geral e conceitos fundamentais

Introduo63 Cliente RADIUS64 Servidor RADIUS64 Servios oferecidos pelo RADIUS64 RADIUS e EAP65 RADIUS e IEEE 802.1165 NAS65 Suplicante66 RADIUS e eduroam66 O protocolo RADIUS66 Formato da mensagem RADIUS67 Tipos de mensagens RADIUS67 Outros campos das mensagens RADIUS68 Alguns atributos transportados nas mensagens RADIUS68 Exemplo (parte 1)69 Exemplo (parte 2)69 Exemplo (parte 3): Cliente autenticado e pacote de Access-Accept retornado ao NAS70 Comandos do FreeRADIUS70
vi
Atividade Prtica 3 Instalao e configurao de um servidor RADIUS 71 Instalando o RADIUS71 Configurando o RADIUS sem federao71 Configurando o ponto de acesso para autenticar em servidor RADIUS 77
5. LDAP Viso geral e conceitos fundamentais

Introduo79 Surgimento do LDAP80 Verses do LDAP80 Operao do LDAP81 Cliente e Servidor LDAP81 Protocolo LDAP 82 Organizao e estruturas do LDAP82 Modelos LDAP83 Modelo de Informao do LDAP83 Tipos de classe de objeto83 Directory Information Tree84 Descrio da rvore e das entradas LDIF84 Esquemas LDAP85 Esquema brEduPerson85 Classes de objetos no esquema brEduPerson86 OpenLDAP86 OpenLDAP: iniciando e parando o servidor87 Atividade Prtica 4 Instalao e configurao de um servidor LDAP87
6. Roaming no eduroam: conceitos e funcionamento

Introduo97 Estrutura hierrquica98 Realms (domnio)98 Infraestrutura do provedor de acesso99 Processo de autenticao local99 Processo de Autenticao Remota100 Servidor de encaminhamento proxy RADIUS100 Atividade Prtica 5 Configurao de proxy para a federao (roaming)101 vii
Configurando o proxy da federao104 Teste de roaming106
7. RadSec: Segurana na comunicao RADIUS

Introduo107 Deficincias na segurana do RADIUS108 Vulnerabilidades do MD5108 Vantagens do RadSec109 Compatibilidade RADIUS UDP vs RadSec109 Autenticao com RadSec110 Implementaes112 O radsecproxy112 Comandos do radsecproxy 113 Atividade Prtica 6 Configurao do proxy com RadSec113 Instalao do RadSec em cada instituio114
8. RADIUS Accounting: conceitos e finalidade

Introduo129 RADIUS Accounting130 Accounting e RadSec130 Mensagens de accounting131 Atributos das mensagens de accounting131 Atributos Acct-Status-Type132 Troca de mensagens133 Accounting e roaming133 Atividade Prtica 7 Configurao do accounting e banco de dados PostgreSQL134 Instalao e configurao do suporte ao accounting134 Instalao do PostgreSQL135 Configurando FreeRADIUS para accounting135 Uso do phppgadmin para visualizar os dados coletados137 Outras ferramentas de visualizao140 Consideraes finais141
Bibliografia 143
viii

A Escola Superior de Redes (ESR) a unidade da Rede Nacional de Ensino e Pesquisa (RNP) responsvel pela disseminao do conhecimento em Tecnologias da Informao e Comunicao (TIC). A ESR nasce com a proposta de ser a formadora e disseminadora de competncias em TIC para o corpo tcnico-administrativo das universidades federais, escolas tcnicas e unidades federais de pesquisa. Sua misso fundamental realizar a capacitao tcnica do corpo funcional das organizaes usurias da RNP, para o exerccio de competncias aplicveis ao uso eficaz e eficiente das TIC. A ESR oferece dezenas de cursos distribudos nas reas temticas: Administrao e Projeto de Redes, Administrao de Sistemas, Segurana, Mdias de Suporte Colaborao Digital e Governana de TI. A ESR tambm participa de diversos projetos de interesse pblico, como a elaborao e execuo de planos de capacitao para formao de multiplicadores para projetos educacionais como: formao no uso da conferncia web para a Universidade Aberta do Brasil (UAB), formao do suporte tcnico de laboratrios do Proinfo e criao de um conjunto de cartilhas sobre redes sem fio para o programa Um Computador por Aluno (UCA).
A metodologia da ESR
A filosofia pedaggica e a metodologia que orientam os cursos da ESR so baseadas na aprendizagem como construo do conhecimento por meio da resoluo de problemas tpicos da realidade do profissional em formao. Os resultados obtidos nos cursos de natureza terico-prtica so otimizados, pois o instrutor, auxiliado pelo material didtico, atua no apenas como expositor de conceitos e informaes, mas principalmente como orientador do aluno na execuo de atividades contextualizadas nas situaes do cotidiano profissional. A aprendizagem entendida como a resposta do aluno ao desafio de situaes-problema semelhantes s encontradas na prtica profissional, que so superadas por meio de anlise, sntese, julgamento, pensamento crtico e construo de hipteses para a resoluo do problema, em abordagem orientada ao desenvolvimento de competncias. Dessa forma, o instrutor tem participao ativa e dialgica como orientador do aluno para as atividades em laboratrio. At mesmo a apresentao da teoria no incio da sesso de aprendizagem no considerada uma simples exposio de conceitos e informaes. O instrutor busca incentivar a participao dos alunos continuamente .
ix
As sesses de aprendizagem onde se do a apresentao dos contedos e a realizao das atividades prticas tm formato presencial e essencialmente prtico, utilizando tcnicas de estudo dirigido individual, trabalho em equipe e prticas orientadas para o contexto de atuao do futuro especialista que se pretende formar. As sesses de aprendizagem desenvolvem-se em trs etapas, com predominncia de tempo para as atividades prticas, conforme descrio a seguir: Primeira etapa: apresentao da teoria e esclarecimento de dvidas (de 60 a 90 minutos). O instrutor apresenta, de maneira sinttica, os conceitos tericos correspondentes ao tema da sesso de aprendizagem, com auxlio de slides em formato PowerPoint. O instrutor levanta questes sobre o contedo dos slides em vez de apenas apresent-los, convidando a turma reflexo e participao. Isso evita que as apresentaes sejam montonas e que o aluno se coloque em posio de passividade, o que reduziria a aprendizagem. Segunda etapa: atividades prticas de aprendizagem (de 120 a 150 minutos). Esta etapa a essncia dos cursos da ESR. A maioria das atividades dos cursos assncrona e realizada em duplas de alunos, que acompanham o ritmo do roteiro de atividades proposto no livro de apoio. Instrutor e monitor circulam entre as duplas para solucionar dvidas e oferecer explicaes complementares. Terceira etapa: discusso das atividades realizadas (30 minutos). O instrutor comenta cada atividade, apresentando uma das solues possveis para resolv-la, devendo ater-se quelas que geram maior dificuldade e polmica. Os alunos so convidados a comentar as solues encontradas e o instrutor retoma tpicos que tenham gerado dvidas, estimulando a participao dos alunos. O instrutor sempre estimula os alunos a encontrarem solues alternativas s sugeridas por ele e pelos colegas e, caso existam, a coment-las.
Sobre o curso
O curso aborda todos os conhecimentos necessrios para a construo do ambiente de autenticao seguro e distribudo oferecido pelo eduroam. O texto est estruturado em oito captulos. Aps a introduo, que oferece uma viso geral do servio eduroam, so estudadas as redes sem fio padro IEEE 802.11, seus mecanismos de segurana e mtodos de autenticao. O padro RADIUS, utilizado para implementar o mecanismo de autenticao distribudo, assim como o LDAP, recomendado para o armazenamento das credenciais dos usurios, so abordados na sequncia. Os ltimos captulos so dedicados a tpicos especiais sobre o servio RADIUS, como as configuraes que permitem a mobilidade (roaming) de usurios entre instituies, o RadSec, que oferece comunicao segura entre servidores RADIUS, e a funcionalidade de accounting, que permite o registro das estatsticas de autenticao e uso da rede. Para realizao do curso em 24 horas, divididas em 6 sesses de 4 horas cada, recomendada a seguinte distribuio: Sesso 1: Captulos 1 e 2 executando a Atividade Prtica 1 no fim da sesso; Sesso 2: Captulo 3 executando a Atividade Prtica 2 no fim da sesso; Sesso 3: Captulo 4 executando a Atividade Prtica 3 no fim da sesso; Sesso 4: Captulo 5 executando a Atividade Prtica 4 no fim da sesso; Sesso 5: Captulo 6 executando a Atividade Prtica 5 no fim da sesso; Sesso 6: Captulos 7 e 8 executando a Atividade Prtica 6 (aps o captulo 7) e a Atividade Prtica 7 no fim da sesso.
A quem se destina
Analistas, gerentes de redes e gerentes de TI de instituies que tenham interesse em oferecer o servio eduroam. ainda destinado a profissionais que desejem adquirir conhecimentos sobre infraestruturas distribudas de autenticao e acesso seguro em redes sem fio.
Convenes utilizadas neste livro

As seguintes convenes tipogrficas so usadas neste livro: Itlico Indica nomes de arquivos e referncias bibliogrficas relacionadas ao longo do texto.
Largura constante
Indica comandos e suas opes, variveis e atributos, contedo de arquivos e resultado da sada de comandos. Comandos que sero digitados pelo usurio so grifados em negrito e possuem o prefixo do ambiente em uso (no Linux normalmente # ou $, enquanto no Windows C:\).
Contedo de slide
Indica o contedo dos slides referentes ao curso apresentados em sala de aula.
Smbolo
Indica referncia complementar disponvel em site ou pgina na internet.
Smbolo
Indica um documento como referncia complementar.
Smbolo
Indica um vdeo como referncia complementar.
Smbolo
Indica um arquivo de adio como referncia complementar.
Smbolo
Indica um aviso ou precauo a ser considerada.
Smbolo
Indica questionamentos que estimulam a reflexo ou apresenta contedo de apoio ao entendimento do tema em questo.
Smbolo
Indica notas e informaes complementares como dicas, sugestes de leitura adicional ou mesmo uma observao.
Permisses de uso
Todos os direitos reservados RNP. Agradecemos sempre citar esta fonte quando incluir parte deste livro em outra obra. Exemplo de citao: SAADE, Dbora Christina Muchaluat; CARRANO, Ricardo Campanha; SILVA, Edelberto Franco. Eduroam: acesso sem fio seguro para Comunidade Acadmica Federada. Rio de Janeiro: Escola Superior de Redes, RNP, 2013. xi
Comentrios e perguntas
Para enviar comentrios e perguntas sobre esta publicao: Escola Superior de Redes RNP Endereo: Av. Lauro Mller 116 sala 1103 Botafogo Rio de Janeiro RJ 22290-906 E-mail: info@esr.rnp.br
Sobre os autores
Dbora Christina Muchaluat Saade professora associada do Departamento de Cincia da Computao da Universidade Federal Fluminense (UFF). engenheira de computao formada pela PUC-Rio e possui mestrado e doutorado em informtica pela mesma universidade. bolsista de produtividade em Desenvolvimento Tecnolgico e Extenso Inovadora pelo CNPq e foi Jovem Cientista do Estado do Rio de Janeiro pela Faperj. Suas reas de pesquisa so redes de computadores, redes sem fio, sistemas multimdia e hipermdia, TV digital interativa e telemedicina. J coordenou diversos projetos de pesquisa financiados pelo CNPq e Faperj e foi coordenadora do projeto piloto Eduroam-br, financiado pela RNP e realizado em parceria com a UFMS, UFRJ e diversas outras instituies, implantando o servio piloto eduroam no Brasil. Ricardo Campanha Carrano engenheiro de telecomunicaes formado em 1995 pela Universidade Federal Fluminense. Em 2008, obteve o ttulo de Mestre em Engenharia de Telecomunicaes pela mesma instituio e atualmente cursa o doutorado em Computao, tambm na UFF, onde atua como Professor do Departamento de Engenharia de Telecomunicaes. Foi empresrio e participou da implantao de provedores de acesso no incio da Internet comercial no Brasil, em 1995. Atuou como Engenheiro de Redes para a ONG internacional One Laptop per Child (OLPC) e j participou de diversos projetos de pesquisa financiados pela RNP, pelo MEC e por empresas privadas. Edelberto Franco Silva se tornou Bacharel em Sistemas de Informao pela Faculdade Metodista Granbery em 2006, e obteve o ttulo de Mestre em Computao pela Universidade Federal Fluminense em 2011. Atualmente Doutorando em Computao pela Universidade Federal Fluminense. Participou de diversos projetos de pesquisa, possuindo experincia na rea de Cincia da Computao, com nfase em redes, atuando principalmente nos temas relacionados a redes sem fio, Internet do Futuro e segurana. Luiz Claudio Schara Magalhes graduado em Engenharia Eltrica com nfase em Sistemas pela PUC-Rio em 1989, Mestre em Cincia de Computao pela PUC-Rio em 1993 e Doutor em Cincia da Computao pela University of Illinois at Urbana-Champaign em 2002. Vem atuando como professor da Universidade Federal Fluminense desde 1994 no Departamento de Engenharia de Telecomunicaes. Coordenou e participou de diversos projetos de pesquisa financiados pela RNP, FAPERJ, CNPq e FINEP, incluindo o projeto piloto Eduroam-br. Seus maiores interesses so redes sem fio, computao mvel e Internet do Futuro. Renato Duarte formado em Cincia da Computao pela UniCarioca e trabalha h treze anos na rea. Atualmente responsvel pela rea acadmica de Mdias de Suporte Colaborao Digital e coordena a equipe de analistas das unidades da Escola Superior de Redes da Rede Nacional de Ensino e Pesquisa (ESR-RNP). responsvel pela infraestrutura de TI de apoio coordenao da ESR, e pelo preparo e validao dos laboratrios para execuo das atividades prticas dos cursos da ESR.
xii
1
Viso geral do eduroam
objetivos
Compreender os principais conceitos envolvidos no servio eduroam, desenvolvendo uma viso geral do servio e de suas tecnologias-chave.
conceitos
Servio eduroam, autenticao e roaming, Federao Acadmica.
Introduo
O education roaming (eduroam) uma iniciativa da Trans-European Research and Education Networking Association (Terena) para oferecer servio de acesso sem fio seguro desenvol vido para a comunidade internacional de educao e pesquisa. O servio eduroam permite que estudantes, pesquisadores e a equipe de instituies participantes obtenham conectividade internet, atravs de conexo sem fio segura, dentro de seus campi e quando visitam as instituies que participam da federao eduroam, de forma transparente. Para ilustrar os ganhos trazidos pelo eduroam, imaginemos que o professor Jos Silva, da Universidade Estadual de Campinas (Unicamp), participa de uma banca na Universidade Federal do Rio de Janeiro (UFRJ). Para que possa verificar seu e-mail, ele solicita uma conta, e os administradores na UFRJ gentilmente criam a conta provisria jsilva, com a senha senha123. No dia seguinte, o professor Jos visita a Universidade Federal Fluminense (UFF), onde dar uma palestra. Nesse caso, para que ele possa se conectar, os administradores da UFF criam a conta jose.silva, segundo sua prpria poltica para a criao de logins, e atribuem a essa conta a senha senha1234, tambm de acordo com sua poltica local. Depois de algumas semanas de seu retorno para Campinas, Jos Silva volta a viajar e, dessa vez, embarca para o Mato Grosso do Sul, onde, em visita Universidade Federal de Mato login jsilva, mas este j era utilizado por outro usurio) e senha 123senha. Passados mais alguns meses, o professor retorna UFRJ e, ao pedir um acesso, lembrado de que j possui uma conta naquela instituio. Mas ser jsilva, jose.silva ou silvaj? E a senha, qual seria? Esse exemplo expe ao menos duas deficincias graves nesse esquema improvisado de autenticao. A primeira a dificuldade que as instituies visitadas tero em criar e, eventualmente, em remover essas contas. Qual o processo para esse tipo de solicitao? Por quanto tempo essas contas devem permanecer vlidas? Quem o responsvel, caso haja abusos? Em segundo lugar, vem a bvia dificuldade do visitante. Ele no pode esperar que se criem os mesmos logins e senhas em todas as instituies visitadas. Como memorizar todas elas?
Captulo 1 - Viso geral do eduroam
Grosso do Sul (UFMS), receber um terceiro par de login e senha: silvaj (o professor pediu o
O eduroam oferece uma resposta para esses problemas. As credenciais usadas pelo professor Jos Silva, de nosso exemplo, sero as criadas em sua instituio de origem (a Unicamp, no caso). No haver necessidade de criao de contas em nenhuma das instituies visitadas para acesso rede sem fio.
jsilva senha123
Por favor, gostaria de acessar a rede?
jose.silva senha1234
Anote o login e a senha!
4 jsilva senha123 jose.silva senha1234 silvaj 123senha

silvaj 123senha
Voc j tem conta aqui, certo?
Conforme se pode ver no mapa da Figura 1.2, o eduroam est presente em diversas instituies ao redor do mundo, organizadas em trs confederaes: uma na Europa, outra
Eduroam: acesso sem fio seguro para Comunidade Acadmica Federada
na Amrica do Norte e a terceira na sia/Oceania. A Amrica Latina iniciou sua insero a partir do projeto piloto Eduroam-br, apoiado pela RNP em parceria com a Cooperao Latino-Americana de Redes Avanadas (RedClara). Em 2012, Brasil e Peru foram autorizados a atuar como roaming operators, oferecendo o servio eduroam na Amrica Latina.
Figura 1.1 Problema de gesto a partir de bases completamente isoladas.
8 16 29 NORTH AMERICA 67
Atlantic Ocean
1224 EUROPE 763 3337 AFRICA
ASIA
48
Pacic Ocean
SOUTH AMERICA
Indian Ocean
AUSTRALIA 393
Figura 1.2 Demonstrao dos continentes inseridos no projeto eduroam aps o ingresso da Amrica Latina (situao em dezembro de 2012) [eduroam, 2012].
O projeto eduroam-br
O projeto eduroam-br iniciou-se em 2011 a partir da motivao de integrao das universidades brasileiras ao servio eduroam mundial. A RNP, junto com as universidades Federal Fluminense, Federal do Rio de Janeiro e Federal de Mato Grosso do Sul deu incio ao piloto que contou posteriormente com mais sete voluntrias (UFSC, Unicamp, UFRGS, UFES, UFMG, UFPA e PUCRS). O projeto piloto Eduroam-br foi concludo em julho de 2012, tornando-se um servio no portflio da RNP.
Tecnologias utilizadas no eduroam

O servio eduroam uma arquitetura distribuda de servidores de autenticao, onde o pedido de autenticao de um usurio sempre tratado em sua instituio de origem. Quando um usurio est em sua prpria instituio, o pedido de autenticao desse usurio para acesso rede de sua instituio tratado pelo servidor de autenticao local. Quando um usurio estiver visitando uma instituio parceira, o pedido de autenticao desse usurio para acesso rede da instituio visitada enviado ao servidor de autenticao de sua instituio de origem para que suas credenciais sejam verificadas. O servio eduroam se baseia na utilizao do padro internacional Remote Authentication Dial In User Service (RADIUS), publicado pelo Internet Engineering Task Force (IETF). A infraestrutura de rede necessria para oferecer o servio, basicamente, utiliza pontos de acesso sem fio IEEE 802.11 e se apoia no padro IEEE 802.1X e no padro IEEE 802.11i para prover mecanismos de acesso seguro. As informaes utilizadas para autenticao de usurios, preferencialmente, devem ser armazenadas em diretrios utilizando bases LDAP. Alm disso, cada instituio deve garantir a credibilidade das credenciais de seus usurios. Sendo assim, o servio eduroam pressupe uma relao de confiana entre as instituies participantes, seguindo o conceito de fede rao. Por isso, para que uma instituio brasileira possa oferecer o servio eduroam, esta deve ser um provedor de identidade (IdP) da Comunidade Acadmica Federada (CAFe).
Saiba mais
Para saber mais sobre a CAFe, visite o site da RNP: http://www.rnp. br/servicos/cafe.html
RADIUS
O Remote Authentication Dial In User Service (RADIUS) um padro IETF, especificado na RFC 2865, que oferece servio de Autenticao, Autorizao e Auditoria (AAA) consolidado no mercado como uma soluo robusta. O protocolo RADIUS opera sobre o protocolo de transporte UDP e utiliza, por padro, a porta 1812. Desenvolvido no incio da dcada de 90 e sendo continuamente atualizado, o RADIUS consegue satisfazer os requisitos das tecnologias emergentes. O servidor RADIUS em conjunto com a infraestrutura IEEE 802.11i um dos mtodos mais seguros para controle de acesso s redes sem fio. Servidores RADIUS so responsveis por: 11 Receber solicitaes de conexo. 11 Autenticar usurios. 11 Retornar todas as informaes de configurao necessrias para o cliente (NAS Network Access Server) prover conectividade a um usurio. 11 Podem atuar como um cliente proxy de outros servidores de autenticao. O objetivo do processo de autenticao a garantia de que o emissor de uma mensagem , de fato, quem ele diz ser. Em geral, a autenticao ocorre entre um cliente e um servidor e pode ser feita atravs da apresentao de uma identidade e suas credenciais correspondentes, como a senha associada, tickets, tokens e certificados digitais. Servidores RADIUS podem ainda funcionar como um cliente proxy, encaminhando as solicitaes de autenticao at outro servidor para que seja realizada a verificao das credenciais do cliente.
Figura 1.3 Logotipo da Comunidade Acadmica Federada.
IEEE 802.11i
A emenda IEEE 802.11i, publicada em 2004, foi desenvolvida justamente para sanar as questes de segurana em redes sem fio 802.11. Uma verso provisria da emenda foi publicada em 2003 com alteraes compatveis com os equipamentos j fabricados, para combater a crescente descrena na tecnologia WiFi. Essa primeira verso do IEEE 802.11i se convencionou chamar WPA1, enquanto WPA2 serve para designar a implementao final do IEEE 802.11i, que requeria mudanas no hardware dos dispositivos. O WPA2 a implementao completa de segurana para rede local sem fio e recomendada para o uso corporativo. Um aspecto importante que ela permite autenticar usurios em vez de mquinas. preciso reconhecer que os mecanismos de chave pr-compartilhada se tornam inseguros pelo reuso constante e ocasional exposio da chave (em avisos pblicos ou pela divulgao boca a boca) e pela necessidade de troca constante, cada vez que um membro da equipe deixa a instituio um procedimento raramente executado. Por esses motivos, a autenticao de usurios, como prevista no WPA2, fundamental. Para alcanar esse objetivo, o IEEE 802.11i recomenda o emprego de outra tecnologia pr-existente, o IEEE 802.1X (nesse caso, o X maisculo).
IEEE 802.1X
O padro IEEE 802.1X um arcabouo (framework) de autenticao para as tecnologias de rede da famlia IEEE 802. Na verdade, o IEEE 802.1X apenas descreve o encapsulamento de um padro pr-existente, o Extensible Authentication Protocol (EAP), sobre os padres IEEE 802. O EAP foi criado pelo IETF, descrito originalmente na RFC 2284, e posteriormente atualizado pela RFC 3748. Inicialmente o EAP era usado apenas sobre enlaces Point-to-Point Protocol (PPP). Foi justamente o padro IEEE 802.1X que ampliou seu uso para outros tipos de enlace. O EAP no descreve um mecanismo de autenticao. Essa autenticao realizada por um protocolo de extenso chamado de Mtodo EAP. Os mtodos podem ser mais ou menos adaptados s necessidades especficas de uma rede.
Arquitetura IEEE 802.1X

a) EAPOL RADIUS
Suplicante b)
Figura 1.4 Comunicao entre o suplicante, o autenticador e o servidor de autenticao RADIUS [Gant, 2002].
Autenticador
Servidor de Autenticao
mtodo EAP EAP 802.1X 802.1 1 802.1X 802.1 1 RADIUS UDP/IP 802.3 RADIUS UDP/IP 802.3
Na arquitetura IEEE 802.1X, apresentada na Figura 1.4, chama-se de suplicante o dispositivo que busca autenticao. No caso das redes sem fio, o suplicante o cliente que se associa rede atravs de um ponto de acesso (AP Access Point). O ponto de acesso tem a funo de autenticador e seu papel intermediar o processo, enviando a informao do suplicante a um Servidor de autenticao RADIUS, que consulta a base de dados de usurios. Entre o suplicante e o autenticador, o protocolo usado o EAP e, entre o autenticador e o
servidor de autenticao, utilizado o protocolo RADIUS.
Comunidade Acadmica Federada

A Comunidade Acadmica Federada (CAFe) uma federao de identidade que rene instituies de ensino e pesquisa brasileiras. Atravs da CAFe, um usurio mantm todas as suas informaes na instituio de origem e pode acessar servios oferecidos pelas instituies que participam da federao. Como se pode observar, o conceito envolvido na CAFe segue o mesmo do eduroam, uma vez que a CAFe possibilita que cada usurio tenha uma conta nica em sua instituio de origem, vlida para todos os servios oferecidos federao, eliminando a necessidade de mltiplas senhas de acesso e processos de cadastramento.
Instituies pertencentes CAFe podem atuar como provedor de identidade (IdP) e provedor de servio (ISP), sendo que a RNP, que mantm esse servio, prov subsdio completo no custo associado ao uso do servio da CAFe a essas instituies. Alm disso, nenhum dos acordos atuais prev qualquer custo para os provedores de servio. A relao de confiana entre instituies participantes da federao permite que o usurio se autentique unicamente em sua instituio de origem, que fornece as garantias de autenticidade e credibilidade necessrias s demais instituies. A base de dados LDAP, que armazena as credenciais para acesso ao servio eduroam no Brasil, a mesma base LDAP utilizada pela instituio provedora de identidade na federao CAFe.
Funcionamento do eduroam
O eduroam utiliza estrutura hierrquica de servidores RADIUS em trs nveis: 11 Confederao. 11 Federao (pas). 11 Instituio.
Maior Nvel de Confederao Servidor RADIUS (resiliente)
Maior Nvel de Federao Servidor RADIUS .BR Nvel Institucional Servidores RADIUS inst-1 inst-2 inst-3 inst-4 .AR
Figura 1.5 Hierarquia de servidores RADIUS no eduroam.
Na estrutura hierrquica de trs nveis utilizada no servio eduroam (representada na Figura 1.5), o terceiro nvel compreende as instituies participantes. Cada instituio representada
por ao menos um servidor RADIUS e sua base de dados LDAP. J no segundo nvel h o ponto central do pas (federao), ao qual a instituio subordinada. Como primeiro nvel dessa hierarquia tem-se o servidor da confederao, que aquele que interliga todos os servidores das federaes participantes. Usurios de cada instituio participante do eduroam possuem como identificao seu domnio associado. Assim como no Domain Name System (DNS), os domnios (Fully Qualified Domain Name FQDN) so formados conforme sua subordinao. Por exemplo, a Universidade Federal Fluminense, que subordinada ao ponto central do Brasil, representado pelo .br, ter como domnio final @uff.br.
Autenticao na instituio de origem

Servidor da Federao eduroam.br proxy RADIUS
Instituio Visitada
inst1.edu.br Servidor RADIUS
Instituio de Origem
inst2.edu.br Servidor RADIUS
inst2.edu.br Usurio em roaming
AP
inst1.edu.br Servidor LDAP
inst2.edu.br Servidor LDAP
Figura 1.6 Exemplo de consulta base local para usurio em roaming entre instituies.
No servio eduroam, o acesso internet atravs de uma instituio parceira denominado roaming e possibilita ao visitante utilizar sua prpria credencial para autenticao. Como exemplificado na Figura 1.6, pode-se imaginar um usurio da instituio inst2.edu.br (exemplo: visitante@inst2.edu.br) visitando a instituio inst1.edu.br. O pedido de autorizao de acesso desse usurio ser recebido pelo servidor RADIUS da instituio visitada, que por sua vez, ao verificar que o domnio relacionado ao usurio no corresponde a um domnio local, encaminhar a solicitao ao servidor de nvel acima (federao). Uma vez encontrada a instituio de origem do usurio, a requisio ento encaminhada a ela, que realiza a verificao necessria e retorna a resposta pelo caminho contrrio.
Figura 1.7 Disposio da hierarquia de servidores latino-americanos e servidores eduroam raiz.
Interconexo com Amrica Latina e Europa

EDUROAM
Proxy LATLR CLARA .pe
Proxys ETLR GEANT
.nl .pe .br
.dk
inictel-uni.edu.pe
uni.edu.pe
u.br
ufrj.br
ufms.br
ufsc.br
unicamp.br
ufrgs.br
A infraestrutura de servidores de autenticao eduroam no mbito nacional se interliga rede eduroam internacional por meio do servidor RADIUS, que representa a confederao latinoamericana. Esse servidor, por sua vez, possui conexo com os servidores redundantes no nvel da confederao eduroam internacional. A Figura 1.7 apresenta esse esquema de interconexo, indicando algumas instituies brasileiras e peruanas que oferecem o servio eduroam. Como comentado, Brasil e Peru foram os primeiros pases da Amrica Latina credenciados como operadores de roaming do eduroam.
2
Redes sem fio IEEE 802.11
objetivos
Conhecer as principais caractersticas do padro IEEE 802.11, assim como os riscos associados a seu uso e suas demandas de segurana. Compreender a necessidade de um sistema de autenticao robusto.
conceitos
Redes sem fio IEEE 802.11. Arquitetura de uma rede IEEE 802.11. Camada fsica (PHY) e camada MAC. Esquemas de segurana WEP e WPA (1 e 2, Personal e Enterprise).
Introduo
Redes locais sem fio tm diversos usos, dentre os quais se destaca o acesso internet. Esse uso bastante comum resultado da proliferao de dispositivos mveis, como laptops, tablets e smartphones, nos quais os modelos que possuem interfaces de rede sem fio so cada vez mais comuns. Esses dispositivos mveis e portteis trazem conforto e flexibilidade aos usurios. Redes sem fio tambm podem ser usadas por computadores fixos, em locais onde o cabea mento pode ser difcil ou impossvel de ser feito, como prdios histricos, e para instalaes provisrias, que no compensam o custo de fazer uma instalao cabeada ou onde fios expostos (pela falta de tubulao adequada) podem atrapalhar a circulao das pessoas.
Redes IEEE 802.11

11 O IEEE 802.11 o padro de redes locais sem fio. 22 Ele foi pensado como uma extenso do padro de redes com fio Ethernet (IEEE 802.3). 11 O padro IEEE 802.11 evolui constantemente, atravs da criao de emendas. 22 A emendas a, g e n determinam camadas fsicas. 22 A emenda i trouxe mais segurana.
q
Captulo 2 - Redes sem fio IEEE 802.11
O Institute of Electrical and Electronic Engineers (IEEE) uma organizao profissional sem fins lucrativos. Seu objetivo promover o conhecimento em reas de engenharia eltrica, computao e telecomunicaes. Isso feito atravs da publicao de revistas e promoo de congressos. Outra das suas atribuies o estabelecimento de padres baseados em consenso. Um padro recebe um nmero, como o IEEE 802.11, que um subpadro do grupo de redes locais e metropolitanas (802), e especifica uma tecnologia de rede local sem fio.
O IEEE 802.11 tem emendas, como o IEEE 802.11g, IEEE 802.11a e IEEE 802.11n. As emendas complementam o padro, atendendo a novas demandas, adaptando o padro a regulamentaes nacionais e acrescentando novas tecnologias para implementao da camada fsica, que determina a tcnica de transmisso e modulao do sinal no meio sem fio. Das trs emendas citadas (a, g e n), cada uma estabelece um padro diferente para redes sem fio. As emendas g e a funcionam respectivamente em 2.4 e 5GHz a taxa de 54Mbps e a emenda n usa tcnicas adicionais para atingir taxas de at 300Mbps em 2.4GHz e 5GHz.
IEEE 802.11 e Wi-Fi

11 Wi-Fi no o mesmo que IEEE 802.11. 11 IEEE 802.11 um padro. 11 Wi-Fi um certificado, dado pela Wi-Fi Alliance, que garante que os produtos com esse certificado falaro entre si. 11 Um produto Wi-Fi no tem de implementar todo o padro IEEE 802.11, apenas a parte necessria para interoperar. 11 Por isso, podemos dizer que Wi-Fi um perfil do IEEE 802.11. Apesar de muitas vezes serem usados como sinnimos, Wi-Fi no o mesmo que IEEE
802.11. O ltimo um padro, enquanto o primeiro se refere certificao da Wi-Fi Alliance, uma cooperativa de indstrias que busca a interoperao de redes sem fio. Todos os produtos com a certificao Wi-Fi podem interoperar. Por outro lado, a certificao Wi-Fi no requer a implementao completa do padro IEEE 802.11. Apenas o perfil esco lhido, e de forma que permita interoperao.
IEEE 802.11 arquitetura e modos de operao

O padro IEEE 802.11 define dois modos de operao, que resultam em duas arquiteturas distintas: 11 Modo infraestruturado:
22 Todo o trfego intermediado por pontos de acesso (AP). 11 Modo ad hoc: 22 No h pontos de acesso, apenas clientes que se comunicam diretamente. Uma rede IEEE 802.11 pode operar em um de dois diferentes modos. Cada um serve a um propsito diferente. O modo sem infraestrutura, chamado modo ad hoc, serve para troca ocasional de informaes, ao passo que o modo infraestruturado serve para estender uma rede com fio. Estudaremos ambos os modos a seguir.
Modos de operao: ad hoc

11 O modo ad hoc serve para interconectar mquinas que estejam prximas para comunicao ocasional. 11 Por exemplo, para trocar arquivos entre os participantes de uma reunio ou para a cooperao entre alunos em uma sala de aula. 11 As mquinas no tm ligao com redes cabeadas, a no ser que seja rodado software de roteamento.
10
Para estabelecer comunicao ocasional entre mquinas vizinhas, usa-se o modo chamado ad hoc. O modo ad hoc permite o estabelecimento de redes locais par-a-par (peer-to-peer) com mltiplas mquinas. Essas mquinas podem, ento, trocar informaes usando qualquer aplicao de rede. A pilha de protocolos TCP/IP roda sobre mquinas em uma rede ad hoc da mesma forma que roda sobre Ethernet. Deve ficar claro que uma rede ad hoc formada por mquinas que conseguem falar entre si diretamente, ou seja, em um nico salto, por exemplo, diversos laptops dentro da mesma sala de reunio. A conectividade em mltiplos saltos possvel atravs da emenda IEEE 802.11s ou do uso de protocolos de roteamento para redes ad hoc, no nvel de aplicao (como OLSR ou AODV, entre outros), mas esse cenrio est fora do escopo deste livro.
Modos de operao: infraestruturado

11 O modo infraestruturado foi feito para estender uma rede com fio. 11 Requer hardware especial: o ponto de acesso. 22 Access Point ou AP. 11 Faz a interface da rede com fio com a rede sem fio. 11 Toda a comunicao passa pelo AP. 22 Mesmo aquela entre dois ns sem fio que poderiam formar uma rede ad hoc entre si. O modo ad hoc no requer nenhum outro hardware alm dos computadores com placas de rede sem fio. J o modo infraestruturado requer um equipamento para fazer a traduo
entre os pacotes da rede sem fio e os pacotes da rede com fio. Esse hardware pode ser at um computador comum fazendo esse papel de gateway de nvel de enlace (bridge ponte). No entanto, o mais comum ter hardware especializado, chamado de ponto de acesso (Access Point ou AP). O papel do AP receber pacotes da rede sem fio e envi-lo para a rede com fio e vice-versa. No modo infraestruturado, a comunicao entre um n da rede sem fio e outro n qualquer (isto , da rede com fio ou sem fio) sempre passar pelo AP. Mesmo que os pontos pudessem se comunicar diretamente (ou seja, ambos os ns tm interfaces de rede sem fio e esto prximos o suficiente para permitir comunicao entre eles), ainda assim o primeiro enviaria os pacotes para o AP e este os enviaria para a outra mquina da rede sem fio. A maior parte das redes sem fio atuais usa o modo infraestruturado. Os pontos de acesso usados em redes pequenas, como as feitas por usurios domsticos, normalmente implementam outras funes, alm de servirem de interface entre a rede com fio e a rede sem fio. Eles incluem um switch, para permitir a ligao de mquinas com fio (pontos de acesso puros s tm uma interface de rede), e separam uma porta desse switch para ser a ligao externa da rede (normalmente denominada porta WAN). Essa porta estaria ligada normalmente ao modem ADLS ou modem para TV a cabo (cable modem). Muitas vezes o prprio dispositivo incorpora um cable modem ou modem ADSL.
11
Componentes em redes ad hoc
Figura 2.1 Exemplo de uma rede ad hoc.
Para construir redes ad hoc, bastam computadores com adaptadores de rede sem fio. Conforme ilustrado na Figura 2.1, esses computadores devem estar prximos o suficiente para garantir sua comunicao direta. Nesse tipo de configurao, as interfaces de rede das estaes falam entre si em vez de com o ponto de acesso.
Componentes em redes infraestruturadas

Rede Cabeada rea de cobertura Ponto de Acesso Sem o Ponto de Acesso Sem o Adaptador Sem Fio (USB) Adaptador Sem Fio (Carto) Adaptador Sem Fio (PCI)
rea de cobertura
Antena extensora de cobertura
Nas redes com infraestrutura, so necessrios, alm dos adaptadores de rede sem fio, pontos de acesso. Os pontos de acesso fazem a interface entre a rede com fio e a rede sem fio. Alm disso, so necessrios cabeamento e elementos de interconexo (como switches e roteadores) para ligar a rede internet (e possivelmente interligar vrios pontos de acesso).
Figura 2.2 Exemplo de ligao entre duas redes sem fio por meio cabeado entre os pontos de acesso.
Arquitetura: Basic Service Set

Uma rede 802.11 composta de um ou mais conjuntos de estaes que se comunicam. Um conjunto de estaes que se comunica definido como um Basic Service Set (BSS). Uma estao (n da rede sem fio) chamada de STA (station).
12
Arquitetura: Independent BSS
Figura 2.3 Exemplo de uma rede ad hoc, onde os ns se comunicam diretamente.
Um BSS independente (Independent Basic Service Set IBSS) um conjunto de estaes que consegue se comunicar entre si. Ele tambm chamado de ad hoc BSS ou rede ad hoc.
Arquitetura: infrastructure BSS

rea de cobertura Ponto de Acesso Sem o
Adaptador Sem Fio (Carto)
Figura 2.4 Exemplo de uma rede sem fio infraestruturada, com a presena de um ponto de acesso.
Uma rede infraestruturada foi definida como aquela que contm um ponto de acesso. Toda comunicao passa pelo ponto de acesso e, se duas estaes do mesmo BSS querem falar uma com a outra, o quadro ser transmitido da estao origem para o ponto de acesso, e deste para a estao destino. Apesar de diminuir a capacidade disponvel na rede sem fio, isso torna a sua implementao muito mais simples, j que estaes no precisam se preocupar se outras esto ou no dentro de sua rea de cobertura, basta estar na rea de cobertura do ponto de acesso. Dessa forma, se uma estao com fio deseja enviar um pacote para uma estao na rede sem fio, ela enviar o pacote para o ponto de acesso, que reenviar o pacote para a estao sem fio de destino. Se uma estao sem fio quer enviar um pacote para outra estao sem fio, em outro BSS, ela enviar para seu prprio ponto de acesso (ao qual est associada), que reenviar o quadro para o ponto de acesso associado estao de destino, que reenviar o quadro para a estao sem fio de destino. Todas essas tarefas requerem que as estaes se registrem com os APs. Isso chamado de uma associao e tem algumas outras atribuies, como auxiliar a segurana da rede. A forma de associao vai ser vista posteriormente, mas requer a troca de trfego de controle entre o AP e a estao. 13
Arquitetura: Extended Service Set

Rede Cabeada rea de cobertura Ponto de Acesso Sem o Ponto de Acesso Sem o Adaptador Sem Fio (USB) Adaptador Sem Fio (Carto) Adaptador Sem Fio (PCI) rea de cobertura
Antena extensora de cobertura
Um nico BSS pode no ser suficiente para cobrir uma rea extensa ou pode ser necessrio colocar mais APs para servir um nmero maior de usurios. Nesse caso, necessrio interligar os BSSs para que estaes possam falar entre si, formando um Service Set Estendido (Extended Service Set ESS). Um ESS um conjunto de BSSs interligados por uma rede, que chamada de sistema de distribuio (Distribution System DS). Um nome, chamado de ESSID (identificador de ESS), usado para identificar um ESS. Todos os BSSs pertencentes ao mesmo ESS tm o mesmo ESSID. A ideia que cada AP que pertena ao mesmo ESS funcione como um switch numa rede que tenha vrios switches interligados. Um switch aprende quais endereos MAC esto atrs de cada porta e envia o quadro para o switch certo dependendo do MAC. Da mesma forma, um AP sabe todos os MACs das
Figura 2.5 Exemplo de ligao/ extenso de duas redes sem fio.
estaes que o esto usando para comunicao e os publica. Isso tambm permite mobilidade entre APs de um mesmo ESS.
Identificadores
Enquanto o ESSID um nome associado a uma rede, o BSSID um endereo, normalmente o endereo MAC do ponto de acesso que define o BSS. Para redes ad hoc, criado um nmero aleatrio de 46 bits (IBSSID). O BSSID formado s de bits 1 reservado para quadros de controle que so usados para busca de pontos de acesso para associao. O ESSID ser usado para associaes (definindo a rede), enquanto o BSSID ser usado para o encaminhamento dos quadros enquanto eles vm de e vo para os pontos de acesso.
Fluxo de dados em um ESS

Uma das vantagens do padro IEEE 802.11 a possibilidade de deslocamento entre diferentes APs, sem perder conexo de rede enquanto estiver se movimentando por eles. O padro permite agrupar vrios BSSs dentro de um ESS. Isso significa que o ESS consiste em um ou vrios BSSs que compartilham o mesmo Identificador de Servio Bsico (SSID). Estaes que faro parte do mesmo ESS podem se comunicar com outras estaes do grupo, mesmo estando em BSS distintas.
14
AP1
BSS 1
AP2
BSS 3 BSS 2 BSS 4
Figura 2.6 Exemplo de BSSs distintos com mesmo SSID, formando um ESS.
AP3
AP4
Na Figura 2.6, quatro BSSs permitem a mobilidade de estaes de forma transparente entre clulas de APs distintos.
SSID
O Identificador de Servio Bsico (SSID) utilizado para o controle dos APs com os quais as estaes desejam se associar. A estao no deve tentar uma associao com o AP, caso ela no tenha o mesmo SSID configurado para iniciar tal mecanismo. 11 O SSID serve para identificar a rede que um cliente est usando. 11 No ponto de acesso, o SSID vem pr-configurado com um nome padro de fbrica: 22 Ex.: SSID = linksys, nos APs da marca Linksys. 11 Esse nome deve ser modificado pelo administrador da rede. J se pensou que o SSID seria a primeira forma de segurana de uma rede. Como o SSID tem de ser conhecido para que uma estao entre na rede, se o SSID no for divulgado, no seria possvel entrar na rede. O problema que trivial descobrir o SSID, ouvindo (sniffing) o trfego da rede. Ento, a ocultao do SSID no deve ser vista como segurana. A funo do SSID no a de prover segurana, mas a de permitir o convvio de diferentes redes na mesma rea. Estaes e pontos de acesso ignoram quadros que tm um SSID diferente do seu, permitindo o compartilhamento do canal.
Sistemas de distribuio
Um sistema de distribuio (Distribution System DS) uma rede de nvel de enlace que interliga os APs (BSSs) de um ESS.
q
Se as redes sem fio forem pensadas como uma extenso das redes com fio (no modo infra estruturado), normal esperar que exista uma rede com fio ligada a cada ponto de acesso. No entanto, como a rede sem fio obviamente uma rede de enlace, no se pode esperar que um ESS consiga se comunicar atravs de um roteador. A interligao entre APs (que definem os BSSs) que formam um ESS tem que ser no nvel de enlace, isto , usando apenas elementos como hubs e switches.
15
Um sistema de distribuio (Distribution System DS) uma rede que interliga os mltiplos APs de um ESS. Na Figura 2.6, um sistema de distribuio interliga os quatro APs. Existem tambm os sistemas de distribuio sem fio (WDS, do ingls Wireless Distribution System), que usam as prprias interfaces sem fio dos APs, mas esse mecanismo no padronizado e apresenta problemas de desempenho.
Conectando-se a uma rede sem fio

O processo de criar uma conexo virtual entre um computador (estao) e a rede (atravs de um ponto de acesso) tem vrios passos: 11 Varredura: encontrar os pontos de acesso (scan). 11 Seleo: escolher o ponto de acesso desejado. 11 Autenticao: identificar-se rede. 11 Associao: associar-se ao ponto de acesso. Em uma rede com fio, o processo de conexo material, isto , feita uma conexo fsica, usando um cabo entre o computador e o elemento ativo de rede. O elemento ativo mais comum um switch. O cabo normalmente no um nico segmento, mas um conjunto de segmentos, dada a prevalncia do cabeamento estruturado. Numa rede sem fio, obviamente isso impossvel, dada a ausncia de cabos. O mtodo de fazer uma conexo virtual entre o computador e o elemento ativo (o ponto de acesso)
chamado de associao. Para haver uma associao, o computador tem de descobrir quais pontos de acesso esto disponveis, j que pode no haver nenhum indcio fsico (isto , os pontos de acesso podem no estar no local ou no estar visveis). O processo de descobrir os pontos de acesso chamado de varredura e ser explicado a seguir. Uma vez descobertos os pontos de acesso disponveis, a estao escolhe um deles para se associar. A forma como essa seleo feita no faz parte do padro, ficando a cargo de cada fabricante. Uma forma usual selecionar o ponto de acesso cujos beacons (quadros peridicos enviados pelo AP) so recebidos com a maior potncia.
A prxima fase se inicia com a troca de quadros de autenticao. Como veremos, apesar do nome, esses quadros no proveem um mecanismo realmente confivel de autenticao. Por isso, uma etapa adicional de autenticao ocorrer aps o trmino da associao. Esse processo ser estudado em detalhes adiante. Como no existe segurana fsica na rede sem fio, em contraste com uma rede com fio onde as tomadas de rede esto dentro das instalaes fsicas, mais um passo necessrio antes de permitir que a conexo virtual seja usada para trafegar dados para alm do ponto de acesso. Esse passo a autenticao, onde a estao vai se identificar como elegvel para usar a rede.
Varredura Passiva e Ativa

11 O processo de identificao da existncia de redes chamado de varredura. 11 Existem dois tipos de varredura: 22 Varredura Passiva: ouvindo os quadros de beacons. 22 Varredura Ativa: envio de Probe Request. 11 A varredura pode ser realizada para uma rede especfica (usando um determinado Basic Service Set ID BSSID) ou para qualquer rede (BSSID = Broadcast).
16
O processo de encontrar quais pontos de acesso esto disponveis chamado de varredura, porque a estao muda seu canal para descobrir pontos de acesso em todos os canais, varrendo a faixa de frequncia destinada ao IEEE 802.11. A varredura ativa se a estao envia um quadro especial (probe request) para identificar a existncia de redes nas proximidades do usurio. Ou passiva, se a estao apenas escuta quadros especiais enviados pelos pontos de acesso (beacons). A varredura tambm pode ser realizada para uma rede especfica (usando um determinado Basic Service Set ID BSSID) ou para qualquer rede (BSSID = Broadcast).
Beacons
11 Quadros de sinalizao disseminados pelo AP (em broadcast) a intervalos regulares. 11 Fazem o anncio da existncia do AP na rede. 11 So mensagens curtas. 11 O intervalo de transmisso ajustvel (o default um quadro a cada 100 ms). Beacons so quadros curtos enviados periodicamente pelos APs para avisar de sua presena e passar algumas informaes necessrias para as estaes que podem querer se
associar a eles. O beacon carrega, entre outras informaes, o nome (SSID) da rede e qual o mtodo de segurana (WEP, WPA) usado pela rede ou se a rede aberta.
Recebendo beacons
AP1
EM (Estao Mvel)
AP2
Figura 2.7 Envio de beacons a todas as estaes mveis em seu raio de alcance.
Envio de Beacons
A Figura 2.7 mostra vrias estaes mveis e dois APs com suas respectivas reas de cobertura. Os APs disseminam beacons na rea de cobertura, contendo mensagens de tempo de sincronizao, servio da camada fsica (quais taxas de transmisso podem ser usadas) e valor do SSID, entre outras.
17
Caso exista interseo das reas de cobertura, uma estao pode receber vrios beacons. A Figura 2.7 ilustra essa situao. A estao em destaque recebe beacons de dois pontos de acesso. APs e estaes podem coexistir na mesma rea e usando a mesma frequncia, visto que os protocolos de acesso ao meio (assunto a ser estudado adiante) estabelecem regras que permitem esse uso compartilhado. No entanto, o normal que os APs prximos sejam colocados em canais ortogonais (no interferentes). Como o processo de varredura passa por todas as frequncias, a estao ser capaz de descobrir os pontos de acesso independente do canal em que operam.
Varredura Passiva
11 A estao sintoniza um canal e espera por quadros de beacon. 11 Como os quadros contm informaes do ponto de acesso, a estao pode criar uma lista de pontos de acesso. 11 O sistema eficiente em relao energia por no exigir a transmisso de quadros pela estao. A varredura passiva refere-se ao processo de procurar por beacons em cada canal. Esses beacons so enviados pelos APs ou estaes (no caso de redes ad hoc), para que estaes
obtenham informaes sobre as redes disponveis (como o valor do SSID da rede). A estao fazendo a varredura tenta, ento, se associar com o BSS utilizando o SSID e outras informaes encontradas.
Mltiplos APs e ESSIDs
AP1
EM descobre: BSS1, AP1 BSS2, AP2 BSS3, AP3
EM (Estao Mvel)
AP2
AP3
AP4
Envio de Beacons
Figura 2.8 Estao mvel recebe beacons de todos os APs que o cobrem.
18
A Figura 2.8 mostra uma estao mvel (Estao Mvel EM) e quatro APs. A estao consegue ouvir beacons vindo dos APs que tm a EM presente na sua rea de cobertura. Nesse exemplo, a EM recebe notificaes de AP1, AP2 e AP3. Como dissemos, a escolha de qual o melhor AP no est no padro. Depender, por exemplo, de qual rede o usurio tem direito de acesso no caso de mltiplas redes ou se todos tm o mesmo ESSID, o AP cujo nvel de sinal recebido (RSSI) for o maior entre os demais APs. As interfaces com o usurio normalmente mostraro as mltiplas redes encontradas (e outras informaes, como canal, codificao e nvel de sinal) e permitiro que o usurio escolha a qual rede ele quer se associar.
Varredura Ativa
11 A estao mvel envia um probe request para cada canal da lista de canais. 11 A estao mvel espera por uma resposta do(s) AP(s). 11 A estao mvel processa o probe response. Na varredura ativa, a estao envia um quadro do tipo probe request. Esse mecanismo ativo utilizado pelas estaes clientes para assegurar a presena de uma rede a qual elas desejem se associar. Esse quadro pode conter o valor do SSID requerido pela estao cliente. Se o SSID for vazio, ento todos os pontos de acesso que ouvirem o probe request vo responder.
AP1
EM (Estao Mvel)
Probe Request
AP2
Figura 2.9 Varredura ativa de uma MS em busca de SSID.
AP3
A Figura 2.9 mostra uma estao mvel (EM) iniciando a varredura ativa, enviando o quadro probe request. Se a requisio tiver um determinado valor de SSID, apenas os APs cujo SSID for equivalente ao solicitado pela EM durante a varredura ativa enviaro o probe response. Se a requisio contiver um valor nulo para o SSID, todos os pontos de acesso naquele canal respondero com o probe response.
Estados de uma estao

Em um dado momento, uma estao pode estar em um dos trs estados:
1. No autenticada e no associada. 2. Autenticada e no associada. 3. Autenticada e associada.
19
Para se autenticar, uma estao trocar quadros de autenticao e, para se associar, quadros de associao. Apenas quando associada, uma estao consegue trocar dados com a rede.
Autenticao
11 Os quadros de autenticao (authentication request e response) trocados nessa fase proveem duas opes: 22 Open system: sistema aberto. 22 Chave pr-compartilhada (PSK). 11 Essa fase de autenticao foi tornada obsoleta pelo IEEE 802.11i. Como veremos adiante, existem dois tipos de autenticao distintos no IEEE 802.11, o primeiro Sistema Aberto (onde o campo Authentication Algorithm Number tem o valor 0)
no prov nenhuma autenticao de fato, ao passo que o segundo ( Authentication Algorithm Number =1) corresponde ao uso de senhas pr-compartilhadas. O IEEE 802.11i, que o mecanismo de autenticao usado pelo eduroam, tornou essa fase de autenticao obsoleta e oferece um mecanismo muito mais efetivo e seguro, que permite a autenticao de usurios. De fato, o esquema de autenticao com chaves pr-compartilhada no mais recomendado pelo padro, apesar de ainda estar disponvel nos pontos de acesso, sobretudo os de uso domstico.
Associao
11 Aps a autenticao, a estao pode tentar se associar enviando um quadro association request. 11 Aps se associar, ela pode utilizar o AP para acessar a rede da qual faz parte. 11 A estao mvel pode se associar somente a uma nica BSS.
Uma vez que a estao mvel tenha sido devidamente autenticada, pode tentar se associar ao AP. Em outras palavras, a associao refere-se ao estado em que a estao cliente passa a fazer parte de uma BSS.
Troca de mensagens para associao

(1) Association Request O AP cria uma entrada para a EM; Envia um ID de associao EM; O AP tem o MAC da EM.
EM (Estao Mvel)
Trfego
Barramento
(2) Association Response (inclui o AID)
AP
Endereo MAC da EM
08:00:45:37:41:7d
AID
Um valor de [1 a 2007)
Figura 2.10 Passo a passo da associao de uma EM a um AP.
20
A Figura 2.10 mostra os estgios de associao de uma estao mvel junto ao AP: 11 O primeiro passo enviar uma requisio de associao (Association Request) ao AP. 11 Recebendo essa requisio e a aceitando, o AP cria uma entrada para a estao e envia uma mensagem de anncio ARP (gratuitous ARP) na rede cabeada com o endereo MAC da estao. Isso a registra nos elementos ativos (switches). Em seguida, envia uma identificao (ID) de associao para a estao via um quadro association response. Nesse intervalo de tempo, o AP j dispe do endereo fsico (MAC) da estao. 11 Uma vez associado, AP e estao comeam a trocar dados.
Depois da associao
AP1 Endereo MAC da EM AID
EM (Estao Mvel)
AP2
Endereo MAC do EM 08:00:45:37:41:7d
AID Um valor de [1 a 2007) AID
08:00:45:37:41:7d
AP3
Endereo MAC da EM
Figura 2.11 Encaminhamento pelo AP a EM de um quadro vindo do PC.
PC
Uma vez associada, quadros enviados da rede cabeada para a estao sero recebidos pelo AP no qual a estao est associada (num mecanismo semelhante ao proxy-ARP). O AP, ento, construir um quadro no formato do IEEE 802.11 e o enviar estao mvel.
Reassociao
11 Quando a estao se desloca, pode haver necessidade de mudana de AP. 11 A reassociao o processo de mudar a associao de um AP antigo para um novo AP quando uma estao mvel estiver se deslocando entre reas distintas. 11 Tambm pode ocorrer quando a estao sai temporariamente da rea de um AP e retorna. 11 APs adjacentes podem interagir uns com os outros durante essa operao. A reassociao define o processo pelo qual uma estao muda sua associao de um AP a outro. Apesar de cada fabricante utilizar mecanismos proprietrios para realizar a reasso-
ciao, o nvel do sinal recebido entre AP e estao continua sendo um dos fatores determinantes para esse mecanismo ocorrer sem interrupo. A reassociao tambm pode ser usada por uma estao quando, por algum motivo, esta perde conectividade com o AP. Como o AP j havia autenticado e associado a estao anteriormente, ela no precisa passar por todo o processo de autenticao/associao novamente. Ao se reassociar, a estao mvel envia para o novo AP o endereo do AP antigo. Isso permite que o AP antigo encaminhe eventuais quadros remanescentes, destinados estao.
21
Desassociao e Desautenticao
11 Para o AP terminar uma associao ou autenticao, ela usa os quadros de disassociation e deauthentication. 11 Um campo chamado reason code traz o motivo.
possvel que um AP queira terminar uma associao ou autenticao. Para isso, ele usa os quadros de desassociao (disassociation) e desautenticao (deauthentication). No nico campo desses quadros, o reason code, vem o motivo do trmino da relao.
Hand over
11 Apesar de no definir como deve ser feito, o IEEE 802.11 traz a base para um meca nismo de mobilidade semelhante ao da rede celular. 11 Estaes mveis podem se locomover dentro da rea de cobertura de um ESS, mudando de um AP para outro. 11 Os APs trocam quadros para atualizar a posio da estao e receber quadros armazenados O IEEE 802.11 permite o hand over (isto , mobilidade) no nvel de enlace. Uma estao
mvel pode trocar de AP dentro de um ESS ao se mover da rea de cobertura de um AP para outro. Os APs trocam mensagens na reassociao, que permite que o estado (se existir) seja exportado de um AP para outro.
IEEE 802.11 Camadas PHY e MAC

802.2 LLC 802.11 MAC Camada de Enlace (MAC)
802.11 FHSS
802.11 DSSS
802.11a OFDM
802.11b HR/DSSS
802.11g ERP
Camada Fsica (PHY)
Figura 2.12 Camadas PHY (fsica) e MAC do padro 802.11.
O padro IEEE 802.11 descreve a camada fsica e a camada MAC de uma rede sem fio. Em termos do modelo de referncia OSI, a camada fsica (PHY) do IEEE 802.11, corresponderia camada 1, ao passo que a camada MAC seria uma parte do que o modelo OSI chama camada de enlace (data link layer) ou camada 2. A parte superior da camada 2 consistiria na subcamada de controle (LLC), descrita pelo padro IEEE 802.2, conforme ilustra a Figura 2.12. A camada fsica responsvel pela codificao e transmisso dos dados no meio fsico, ou seja, descreve as tcnicas de codificao e modulao. Assim, enquanto a camada fsica trata de bits, na camada de enlace, a unidade de informao o quadro (frame). A rigor, o termo pacote deve ser usado apenas no contexto da camada trs (camada de rede), que no caso de uma rede TCP/IP a camada IP. Assim, nos referiremos sempre a quadros IEEE 802.11, sendo os pacotes IP transportados por quadros 802.11.
Camada fsica (PHY)

11 Diz respeito s tcnicas de transmisso e modulao. 11 Camada 1 do modelo OSI de referncia.
22
11 Evoluiu no IEEE 802.11 (b,a,n,g = bang!). 22 802.11 infravermelho, FHSS (2,4GHz) e DSSS (2.4GHz). 22 802.11b DSSS (2.4GHz). 22 802.11a OFDM (5 GHz). 22 802.11g ERP (diversos) (2.4GHz). 22 802.11n novo PHY (2.4GHz e 5GHz).
Ao longo de sua evoluo o padro IEEE 802.11 incorporou uma srie de tcnicas de modulao e codificao distintas. Redes 802.11 utilizam duas faixas do espectro de uso no licenciado na maior parte do mundo, inclusive no Brasil. Essas faixas so chamadas Industrial, Scientific and Medical (ISM) e, como o nome indica, so reservadas para uso industrial, mdico e cientfico, e podem ser usadas por qualquer dispositivo, contanto que a potncia transmitida no ultrapasse certos valores legais. A primeira a chamada banda S-ISM, que abrange as frequncias entre 2,4 e 2,5 GHz. Essa a faixa utilizada pelas implementaes 802.11b e 802.11g. Trata-se de uma poro do espectro com diversos dispositivos emitentes, como fornos de micro-ondas e alguns modelos de telefones sem fio. tambm usada por dispositivos IEEE 802.15.1 (bluetooth). Por conta de seu uso no licenciado e da extrema popularidade dos dispositivos que nela operam, a faixa do espectro de 2,4 GHz j se encontra extremamente disputada nas principais reas urbanas do mundo. As caractersticas de propagao e o baixo poder de penetrao dessas frequncias implicam a necessidade de visada direta para distncias maiores do que algumas dezenas de metros, considerando as potncias legalmente aceitveis. A segunda faixa do espectro utilizada por dispositivos 802.11, no caso os que seguem a emenda a, chamada banda C-ISM e abrange as frequncias entre 5,725 e 5,875 GHz. Os dispositivos 802.11a no alcanaram a mesma popularidade dos dispositivos 802.11b ou 802.11g e tambm por isso sua operao est menos sujeita a interferncia, apesar de a necessidade de visada direta ser ainda maior nessas frequncias.
Canais na faixa de 2,4 GHz

Canal Freq. Central (MHz)
1 2412
2 2417
3 2422
4 2427
5 2432
6 2437
7 2442
8 2447
9 2452
10 2457
11 2462
Canais
Figura 2.13 Demonstrao dos canais da faixa 2,4GHz.
10
11
2,412
2,437
2,462
Freq (GHz)
Na faixa de 2,4GHz, cada canal est separado por 5MHz. Assim, o canal 1 tem a frequncia central em 2.412MHz, enquanto a frequncia central do canal 2 2.417MHz (2.412+5). No entanto, os padres b e g empregam canais de transmisso com 22MHz de largura, o que implica que uma transmisso em um canal usar frequncias de canais adjacentes, como indicado na Figura 2.13.
23
fcil ver que uma separao de cinco canais necessria para que duas transmisses possam ocorrer simultaneamente. Por esse motivo, sugerido o uso dos canais 1, 6 e 11, chamados canais ortogonais ou no interferentes, quando se pretende a instalao de vrias redes ou pontos de acesso prximos. Apesar de no Brasil a Anatel regulamentar apenas o uso de 11 canais, existem pases, como o Japo, onde 14 canais esto disponveis para o uso de redes Wi-Fi.
Canais na faixa de 5GHz

Canal Freq. Central (MHz) 36 5180 40 5200 44 5220 48 5240 52 5260 56 5280 60 5300 64 5320
5 MHz
5180 MHz
5200 MHz
5220 MHz
5240 MHz
5260 MHz
5280 MHz
5300 MHz
5320 MHz
Canais do padro 802.11a

Na faixa de 5GHz, os canais so numerados tambm em intervalos de 5MHz, iniciando do canal 0 (frequncia central 5.000MHz at o canal 199 (frequncia central em 5.995MHz). No padro 802.11a os canais tm 20MHz de largura, o que tambm implica a interferncia entre canais adjacentes, por isso, os canais para Wi-Fi nessa faixa so alocados com inter Eduroam: acesso sem fio seguro para Comunidade Acadmica Federada
Figura 2.14 Demonstrao dos canais da faixa 5GHz .
valos de quatro canais: 36, 40, 44 etc. Na verdade, a banda de 5GHz subdividida em trs subfaixas, onde o limite de potncia permitido varia. A primeira subfaixa, representada na Figura 2.14, possui oito canais ortogonais alocados entre 5.150MHz e 5.350MHz, sendo o primeiro o canal 36 (frequncia central 5.180MHz, seguido pelo 40, 44, e assim por diante, at o canal 64). As outras subfaixas so 5470-5725 MHz (para os canais 100, 104, 108, ..., 140) e 5725-5850 MHz (para os canais 149, 153, 157 e 161), perfazendo um total de 23 canais no interferentes (ao passo que na faixa de 2.4GHz existem apenas 3).
Taxas do IEEE 802.11

11 Redes multitaxas. 22 b 1, 2, 5.5 e 11 Mbps. 22 g 1, 2, 5.5, 6, 9, 11, 12, 18, 24, 36, 48 e 54 Mbps. 22 g puro 6, 9, 12, 18, 24, 36, 48 e 54 Mbps. 22 a 6, 9, 12, 18, 24, 36, 48 e 54 Mbps.
24
11 Controle de taxa item sensvel. 22 Interoperabilidade. 22 Compromisso entre eficincia e robustez.
A possibilidade de estaes operando com codificaes diversas coexistirem na mesma rede aumenta a complexidade dos projetos prticos de redes sem fio. A necessidade de todas as estaes, seja qual for sua taxa de associao (isto , a codificao sendo usada para comunicao entre dois pares), reconhecerem as informaes de controle obriga o uso da codificao na taxa base para os dados de controle, sendo que a taxa base a mais baixa suportada pelo padro. O resultado que a taxa nominal muito maior do que a efetivamente disponvel como banda til para dados. Por isso, os clculos de disponibilidade de banda so complexos, visto ser impossvel definir, a priori, qual ser a taxa de associao das diversas estaes. Os pontos de acesso possuem mecanismos que permitem estabelecer uma taxa de associao mnima. Esses mecanismos so teis porque impedem que estaes muito afastadas se associem a um ponto de acesso usando uma taxa baixa, o que diminuiria a disponibilidade de banda para todas as estaes associadas quele ponto de acesso. Essa restrio tende a reduzir o raio de associao (a distncia que uma estao precisa estar do ponto de acesso), o que permite maior densidade de pontos de acesso. No entanto, isso pode gerar zonas de sombra e causar conexes intermitentes, j que flutuaes do nvel de sinal so norma para redes sem fio. Alm disso, a taxa de transmisso entre uma estao e um ponto de acesso deve satisfazer um compromisso delicado. Transmisses a taxas mais baixas so mais robustas (menos susceptveis a erros), mas ocupam o meio por mais tempo, ao passo que transmisses a taxas maiores fazem uso mais eficiente do meio compartilhado, mas so mais susceptveis a erros. O algoritmo de adaptao de taxa, cujo trabalho encontrar essa taxa de transmisso tima, no faz parte do padro IEEE 802.11, ficando sua implementao a cargo dos fabri cantes de dispositivos Wi-Fi.
Camada MAC
11 A camada MAC define as regras para uso compartilhado do meio. 22 MAC = Medium Access Control (Controle de Acesso ao Meio). 11 A ideia evitar colises (em vez de detect-las). 22 Ethernet CSMA/CD (detecta coliso). 22 Wi-Fi CSMA/CA (evita coliso).
22 Perda de quadros por corrupo mais comum em redes sem fio. Apesar dos objetivos comuns, o controle de acesso ao meio descrito no padro IEEE 802.11 difere do descrito na respectiva camada MAC do padro IEEE 802.3 (Ethernet) justamente por conta das caractersticas do meio de propagao sem fio. A transmisso de rdio, em espao livre, traz desafios que uma rede cabeada no apresenta. Em uma rede Ethernet possvel detectar durante a transmisso quando uma coliso ocorreu e, dessa forma, retransmitir os quadros perdidos. Em redes sem fio, no entanto, isso no acontece. Transmissores de rdio no so capazes de escutar o meio ao mesmo tempo em que transmitem, o que dificulta uma proposta de deteco de coliso. Alm disso, os custos de
11 Tambm importante aumentar a confiabilidade.
25
uma coliso em redes sem fio so altos se comparados aos mesmos custos em uma rede cabeada, onde as taxas de transmisso so usualmente maiores. At porque a perda de quadros por corrupo na transmisso um evento raro em redes cabeadas e relativamente comum em redes sem fio.
CSMA/CA
Carrier Sense Multiple Access with Collision Avoidance: 11 Escuta o meio. 11 Est livre por um tempo maior que DIFS? 22 SIM transmite. 22 NO entra em regime de backoff.
Para finalizar nossa descrio da camada MAC do IEEE 802.11, falta descrever a forma como as estaes disputam o meio quando desejam transmitir. Ou seja, devemos detalhar o funcionamento da funo de coordenao distribuda (Distributed Coordination Function DCF) do padro de uma forma algortmica. Quando uma estao deseja transmitir, ela escuta o meio para determinar se h outra transmisso em curso. Se o meio estiver livre h pelo menos um intervalo de tempo DIFS (DCF Interframe Space), a estao transmite seu quadro imediatamente. No entanto, se a estao detecta o meio como ocupado, ela dever entrar em um regime de backoff. Nesse estado, a estao dever sortear uma quantidade aleatria de slots de tempo, que dever observar aps o meio ser detectado como livre. Ou seja, mesmo depois da transmisso corrente terminar, a estao aguardar um tempo aleatrio antes de iniciar sua transmisso. Esse mecanismo foi concebido para reduzir a probabilidade de colises, j que existe a possibilidade de outras estaes tambm estarem aguardando para transmitir (disputa pelo meio).
Figura 2.15 Diferentes backoffs na transmisso de cinco estaes.
O backoff exponencial
SIFS + ACK + DIFS Frame
B Backo C Frame
Frame
Frame
Frame
TEMPO
26
Na Figura 2.15, possvel avaliar a atividade de cinco estaes na transmisso de seus dados. O sistema comea com uma estao A transmitindo um quadro. Ao trmino desse quadro, todas as estaes esperam o SIFS + ACK + DIFS (SIFS Short IFS; ACK acknowledgement). Nesse momento, as estaes que possuem dados para transmitir escolhem tempos aleatrios (backoffs); na figura claramente podemos ver que a estao C escolhe um tempo menor, em segundo lugar a estao D e em seguida a estao B. Aps decrementar o valor de backoff, a estao C escuta o meio e verifica se nenhuma outra estao est transmitindo, e a transmite seus dados. Ao final da transmisso da estao C, todas as estaes aguardam SIFS + ACK + DIFS. Observe que nesse momento a estao E tem dados para transmitir. Todos os tempos de backoff sero decrementados e a estao D chegar primeiro ao fim desse perodo e far a transmisso. No prximo intervalo, a estao E transmite e por ltimo a estao B transmite. Esse exemplo ilustrativo de como a injustia com a estao B, em mdia, no existe para um grande perodo de tempo de observao.
O quadro 802.11
11 O cabealho MAC tem 30 bytes. 11 Proviso para quatro endereos. 11 4 bytes ao final para verificao de integridade (CRC). 11 O corpo do quadro tem at 2312 bytes. 22 Esse tamanho aumentado para 7995 (emenda n).
Cabealho MAC 2 Quadro de Controle 2 Durao/ID (ou Identicador) 6 Endereo 1 6 Endereo 2 6 Endereo 3 6 Nmero de Sequncia 2 Endereo 4 0-2312 Corpo do Quadro 4
FCS
Figura 2.16 Formato do quadro 802.11.
A Figura 2.16 mostra o formato de um quadro IEEE 802.11. Uma das caractersticas mais importantes a presena de quatro endereos MAC (ADDR1-4). Enquanto em uma rede Ethernet s so necessrios dois endereos de 48 bits para enviar um pacote da origem para o destino, em uma rede sem fio, um pacote a caminho de seu destino pode ter de passar por intermedirios (como pontos de acesso). Esses intermedirios so o destino imediato do pacote, mas no seu destino final. Assim, necessrio apont-los, bem como identificar o destino final para que o quadro chegue a ele. Os endereos so numerados, em vez de terem um nome, porque sua funo varia de acordo com o tipo do quadro. Geralmente, o endereo 1 (ADDR1) o destino imediato do reo 3 usado para filtragem no receptor. Cada endereo pode ter uma das seguintes funes: 11 Endereo de destino: destino final do quadro. 11 Endereo de origem: endereo de quem gerou o quadro. 11 Endereo do receptor: qual estao deve processar o quadro. 11 Endereo do transmissor: qual estao enviou aquele quadro. 11 Identificao do Basic Service Set (BSSID): como vrias redes locais podem compartilhar a mesma rea, esse endereo permite identificar em que rede sem fio o quadro transmitido. 27
pacote (isto , identifica o receptor), o endereo 2 (ADDR2) identifica o transmissor e o ende -
A maior parte dos quadros usa trs endereos (1-destino, 2-origem, 3-rede/BSSID). O campo frame control ser detalhado adiante. O campo Duration informa o tempo estimado em que o meio estar ocupado pela transmisso corrente, ao passo que o Sequence Control carrega informaes para remontagem do quadro, caso ele tenha sido fragmentado e tambm ajuda na identificao de quadros duplicados. Aps o corpo (Frame Body), o quadro traz um checksum baseado em Cyclic Redundancy Check (CRC), que permite a verificao de integridade (se o quadro foi corrompido durante a transmisso). O corpo do quadro em si aumenta de 2312 (tamanho mximo) para 7995, quando a emenda n for utilizada.
Endereos MAC
11 Endereos MAC esto para os quadros IEEE 802.11 como os endereos IP esto para os pacotes IP. 11 Endereos de 48 bits (6 bytes). 11 Duas partes: 22 OUI identifica fabricante (3 bytes). 22 ltimos 3 bytes identificam dispositivo.
Assim, como no padro Ethernet, o 802.11 utiliza endereos MAC de 48 bits para identificar dispositivos. Estes so divididos em duas partes, sendo que a primeira metade identifica um fabricante, enquanto o restante designa um dispositivo. A no ser por fraudes ou erros na fabricao, cada dispositivo Wi-Fi tem um endereo nico.
Endereo de destino
11 Unicast: um destinatrio. 22 Primeiro byte par (exemplo 00:01:02:03:04:05). 11 Multicast: diversos destinatrios. 22 Primeiro byte mpar (exemplo 01:02:03:04:05:06).
11 Broadcast: todos. 22 FF:FF:FF:FF:FF:FF
Unicast
Multicast
Broadcast
Figura 2.17 Ilustrao do envio em Unicast, Multicast e Broadcast.
Quadros podem ser destinados a um destinatrio nico ou a um grupo de destinatrios. No primeiro caso, teremos uma transmisso unicast e, portanto, um endereo de destino unicast. As transmisses para grupos so chamadas de multicast. Um caso particular das transmisses multicast de especial interesse o broadcast uma transmisso destinada para todos os participantes de uma rede. Nos endereos de unicast, o primeiro bit transmitido sempre um 0, ao passo que nos endereos de multicast o primeiro bit 1. O endereo de broadcast tem todos os bits iguais a 1 (FF:FF:FF:FF:FF:FF, em notao hexadecimal). Como os bytes dos endereos so transmi-
28
tidos na ordem reversa, o primeiro bit transmitido ser o bit menos significativo do primeiro byte, por isso, os endereos unicast tero o primeiro byte par (um nmero binrio, cujo bit menos significativo zero, sempre um nmero par). No 802.11 todos os quadros unicast devem ser confirmados pelo destinatrios. Ou seja, ao receber um quadro endereado exclusivamente a ele, o dispositivo deve responder com um quadro especial, chamado acknowledgment (ack). Quadros para endereos de grupo no precisam ser confirmados.
Vazo efetiva das redes Wi-Fi

Data Throughput
12 11 10 9 8 7 Mbits/s Tempo ocioso Prembulo PLCP Cabealho PLCP
Figura 2.18 Overhead de transmisso no padro 802.11b em suas diversas taxas.
6 5 4 3 2 1 0 1 2 5,5 11 Mbits/s
Cabealho MAC + ACK Cabealho LLC/SNAP Cabealho TCP/IP Dados
O grfico de barras da Figura 2.18 mostra a eficincia percentual de cada uma das taxas de uma rede IEEE 802.11b. Observe que a menor eficincia existe para a taxa de 11 Mbps. Isso acontece porque parte dos cabealhos so transmitidos a taxas mais baixas, provocando forte deteriorao. Fica claro pelo grfico que existe grande penalidade para as estaes que esto nessa taxa. Para as taxas menores, essa perda proporcionalmente menor. Observe que, no caso de redes IEEE 802.11g operando com estaes IEEE 802.11b, existe forte deteriorao. No se pode esperar que exista grande desempenho quando as duas redes so misturadas.
Como dissemos, existem APs que permitem estabelecer a menor taxa com a qual um usurio poder se associar ao AP. Essa funo especialmente interessante para evitar degradao da rede com a presena de usurios de baixa taxa. Essa situao, caso no seja resolvida de outra forma, deve ser considerada de modo bastante srio. Essa preocupao maior para ambientes com grande mobilidade dos usurios, uma vez que existe mistura grande de perfis. Nesse caso, a alterao da posio dos usurios pode prejudicar o desem penho da rede como um todo. No entanto, vale lembrar que a coibio do uso de taxas menores resulta em diminuio da rea de cobertura da rede sem fio, j que as transmisses a taxas menores tm maior alcance.
29
Segurana em redes IEEE 802.11

11 O problema da segurana mais grave nas redes sem fio. 11 Os padres de segurana. 22 WEP (obsoleto). 22 A emenda i surgiu para melhorar a segurana das redes IEEE 802.11. 33 WPA1: retrocompatibilidade com hardware legado. 33 WPA 2: novos algoritmos para um novo hardware. 33 WPA Personal: autenticao baseada em chave pr-compartilhada. 33 WPA Enterprise: uso de servidor de autenticao.
O problema da segurana
11 O trfego no confinado. 22 No necessrio o acesso fsico infraestrutura. 11 Os trs objetivos bsicos da segurana: 22 Privacidade: garantia de sigilo das mensagens. 22 Integridade: mensagens no adulteradas. 22 Autenticidade: agentes devidamente identificados. Segurana um tpico de extrema importncia em redes de computadores. Os procedimentos e tcnicas de segurana existem para combater o mau uso dos recursos compartilhados, afastar usurios mal intencionados e garantir a privacidade e a integridade dos
dados trafegados e armazenados, assim como garantir a autenticidade dos agentes, ou seja, se um indivduo, mquina ou programa de fato quem afirma ser. Os objetivos acima so comuns a todas as redes de computadores, mas so mais difceis de alcanar em redes sem fio. Quando a conexo entre os computadores em uma rede feita atravs de cabos, a sua invaso s possvel atravs do acesso direto infraestrutura
cabeada, mas em redes sem fio, onde a comunicao feita pelo ar, a segurana se torna mais importante e complicada. Na ausncia de um mecanismo de segurana, qualquer indivduo com uma antena e um receptor de rdio sintonizado na frequncia de operao correta pode interceptar a comunicao ou utilizar os recursos dessa rede. O problema clssico da segurana costuma ser dividido em: garantir privacidade (os dados s podem ser acessados pelo remetente e pelo destinatrio legtimos); integridade (os dados no so adulterados) e autenticidade (os agentes envolvidos so de fato quem afirmam ser). Nossa principal preocupao neste curso est ligada s questes de autenti cao, que sero abordadas novamente, e em maior profundidade, na prxima seo.
Problemas tpicos das redes sem fio

11 Associao no autorizada. 22 Proposital. 22 Acidental. 11 Negao de servio (Denial of Service DoS). 22 Voltada aos elementos da rede (ponto de acesso). 22 Voltada ao espectro (jamming). 11 Interceptao de trfego.
30
Alm de todos os problemas usuais das redes cabeadas, em redes sem fio existem outros especficos. O mais tpico problema de segurana nas redes Wi-Fi o simples uso no auto rizado, atravs da associao ao ponto de acesso o caso prosaico do vizinho que utiliza a rede sem fio desprotegida do apartamento ao lado. Como a banda em uma rede sem fio limitada em comparao s redes cabeadas, e tambm porque a conexo do vizinho tende a ser mais lenta (por conta da distncia), essa conexo clandestina penalizar o usurio legtimo. Esses acessos clandestinos so, em muitos casos, no intencionais. Muitos sistemas esto configurados para tentarem a associao automaticamente ao ponto de acesso com sinal mais forte. A negao de servio uma tcnica de agresso cujo objetivo tornar uma rede ou recurso da rede invivel. O Denial of Service (DoS) no um problema exclusivo das redes sem fio, mas nelas mais grave por duas razes centrais: (1) uma rede sem fio operando em modo infraestrutura tem um ponto central (o ponto de acesso) que, se desabilitado, tornar toda a rede invivel e (2) um dispositivo que gere rudo na faixa de frequncias onde a rede opera (jamming) pode ser utilizado sem a necessidade de qualquer tcnica computacional de segurana e mesmo sem a necessidade do acesso fsico uma antena direcional pode convergir a energia na rea da rede e inviabiliz-la. Finalmente, a interceptao de trfego em uma rede sem fio pode ser realizada com relativa facilidade. Basta acessar o canal correto. Novamente o acesso fsico pode no ser necessrio, bastando o uso de antenas adequadas por parte do agressor.
Padres de segurana no Wi-Fi

Cronologia dos mecanismos de segurana: 11 WEP. 22 1997 parte do padro. 11 WPA. 22 2002 baseado em um draft do IEEE 802.11i. 22 Personal e Enterprise. 11 WPA2. 22 2004 verso final do IEEE802.11i. 22 Personal e Enterprise. O primeiro padro de segurana, o Wired Equivalent Privacy (WEP), era parte integral do padro original IEEE 802.11, lanado em 1997. A promessa, ao menos no nome, era prover um grau de segurana equivalente ao de uma rede cabeada, mas, como veremos, esse objetivo no foi alcanado.
Diante do fracasso do WEP, o IEEE formou a fora tarefa i (TGi Task Group i) para propor mecanismos de segurana mais efetivos. Uma verso preliminar (draft) da emenda i foi a base para o que a Wi-Fi Alliance batizou como Wi-Fi Protected Access (WPA), lanado no final de 2002 e disponvel em produtos a partir de 2003. O trabalho do TGi foi finalizado e publicado em 2004 e deu origem ao mecanismo conhecido como WPA2. Como veremos, ambos os mecanismos WPA e WPA2 podem ser implementados nas vertentes Pessoal (Personal) ou Empresarial (Enterprise).
31
WEP
11 Wired Equivalent Privacy. 11 Mecanismo original do IEEE 802.11. 11 Chave pr-compartilhada (PSK). 11 Algoritmo de criptografia RC4. 22 Chaves de 40 ou 104 bits. 11 Integridade baseada em CRC32. Como dissemos, o Wired Equivalent Privacy (WEP) parte do padro IEEE 802.11, de 1997.
Para garantir que apenas os usurios autorizados pudessem ter acesso rede, o WEP exige que uma senha seja configurada no ponto de acesso e distribuda para todos os usurios. A senha, nesse caso, chamada de chave mais especificamente de chave pr-compartilhada (PSK Pre-Shared Key). O algoritmo de criptografia escolhido para aplicar essa chave ao contedo do quadro foi o RC4. Para garantir que o contedo do quadro no foi adulterado, os quadros WEP incorporam um campo Cyclic Redundancy Check (CRC) de 32 bits.
WEP: cifragem
11 O algoritmo de cifragem do WEP o RC4. 22 Algoritmo de criptografia de fluxo (streamcipher). 22 Muito utilizado (SSL e TLS). 11 Tamanho das chaves criptogrficas : 22 40 (64 - 24) bits. 22 104 (128 -24) bits.
mensagem 1 0 1 1 1 0 0 XOR chave 1 1 1 0 1 1 0 mensagem cifrada 0 1 0 0 0 1 0
O algoritmo de criptografia escolhido pelo padro foi o RC4 (Rons Cipher 4), empregado em diversas outras aplicaes, como Secure Socket Layer (SSL) e Transport Layer Security (TLS) amplamente utilizados na internet. Trata-se de um algoritmo de fluxo (outro tipo comum o algoritmo de bloco). Nessa classe de mecanismos criptogrficos, a mensagem combinada com um fluxo contnuo de bits (a chave) para gerar um texto cifrado. Quando a chave menor do que a mensagem, o que acontece quase sempre, a chave repetida quantas vezes forem necessrias. O mecanismo muito simples, mensagem e chave so combinadas por uma operao binria de ou exclusivo (XOR), resultando na mensagem cifrada. Um XOR resulta em 0 se os operandos (chave ou mensagem) forem iguais, e 1 se forem diferentes.
Figura 2.19 Operao de cifragem da mensagem realizada pelo WEP, baseada na operao XOR.
32
H certa confuso em relao ao tamanho das chaves. Existem duas alternativas, as chaves de 40/64 bits ou as chaves de 104/128 bits. A confuso vem do fato de o usurio informar apenas uma parte da chave, que complementada por um elemento chamado vetor de inicializao, que tem 24 bits. Assim, no caso de uma senha de 128 bits, o usurio escolher apenas 104, ao passo que no caso das chaves de 64 bits, ele escolher apenas 40 bits.
WEP: integridade
O mecanismo de verificao de integridade o CRC32. 11 Fcil e rpido de calcular. 11 Criptograficamente fraco. 22 No impede adulterao transparente do quadro.
O Cyclic Redundancy Check (CRC) um mecanismo de verificao de integridade. Trata-se de um bloco de 32 bits que calculado a partir de parte do quadro protegido pelo WEP e transmitido ao final do quadro. Ao receber o quadro, o destinatrio repete o mesmo clculo. Se encontrar um CRC diferente do recebido isso indicar que o quadro (ou o prprio CRC) foram alterados. A alterao pode acontecer intencionalmente (causada por um agressor) ou acidentalmente (quadro corrompido, por exemplo, pela presena de rudos durante a transmisso). O CRC pode ser comparado aos dois dgitos finais de um CPF, que so calculados em funo dos nove primeiros. O problema que o processo criptograficamente fraco e pode ser manipulado pelo agressor, permitindo que adultere o quadro sem que isso seja detectado.
Problemas do WEP
11 RC4 mal implementado. 22 Chaves curtas. 22 Reso frequente das chaves. 22 Uso prolongado das chaves. 11 CRC no forte o suficiente. 11 Vetor de inicializao. 22 Revela parte da senha. 11 PSKs so intrinsecamente inseguras.
Dado o poder computacional atual dos computadores pessoais, chaves de 40 bits so demasiadamente curtas. Mesmo as de 104 bits no so fortes o suficiente. Para piorar, o WEP possui deficincias que o tornariam vulnervel mesmo com chaves mais longas. O reuso frequente de uma chave, e por perodos longos, a torna vulnervel. Em sntese, o algoritmo RC4, que considerado razoavelmente seguro, no foi implementado da forma correta e tornou-se ineficaz. Alm disso, como dissemos, o CRC uma tcnica incapaz de proteger o quadro contra adulteraes. Outra srie de problemas do WEP est ligada a um elemento chamado Vetor de Inicializao. Esse campo do quadro WEP transmitido em texto plano (sem criptografia) e consiste nos primeiros 24 bits da chave criptogrfica. Revelar uma parte da chave auxilia no processo de criptoanlise (ataque criptografia). Finalmente, o uso de chaves pr-compartilhadas um procedimento intrinsecamente inseguro. Afinal, as chaves tm de ser escolhidas pelo administrador da rede, configuradas
33
no ponto de acesso e distribudas para todos os usurios. A experincia mostra que essas chaves dificilmente so trocadas com a periodicidade recomendada. E, por ltimo, um segredo compartilhado no um segredo.
WPA 1
O IEEE reconheceu as deficincias do WEP e criou a TGi (fora-tarefa i). 11 O WPA 1 foi lanado em 2002 baseado numa verso preliminar do trabalho do TGi. 22 Retrocompatibilidade foi um objetivo. 22 O WPA 1 consideravelmente mais forte do que o WEP. 11 Protocolo de Criptografia TKIP. 22 Ainda sobre RC4 para poder ser executado no mesmo hardware.
Uma vez reconhecidas as falhas do WEP, o IEEE estabeleceu o TGi para tornar as redes Wi-Fi mais seguras. De qualquer maneira, o estrago j estava feito e as redes sem fio continu aram sendo percebidas como inseguras durante muitos anos, apenas recentemente tendo vencido esse estigma. Uma preocupao do comit foi garantir que os dispositivos Wi-Fi j vendidos ainda pudessem ser aproveitados. A ideia era, portanto, criar melhorias que ainda pudessem ser utilizadas pelos dispositivos lanados com WEP, bastando uma alterao de software. A retrocompatibilidade implicava em continuar usando a cifragem RC4, j que esta estava presente no hardware das placas Wi-Fi. A criptografia um processo computacionalmente custoso e, por isso, muitas vezes implementada em chips especializados. Trocar o algoritmo obrigaria a troca do hardware. O WPA foi suficientemente bem-sucedido e, mesmo a padres atuais, prov um nvel de segurana aceitvel para a maioria das redes. O novo protocolo de criptografia, TKIP, abordado a seguir.
WPA 1: TKIP
Novo esquema para verificao de integridade da mensagem. 11 Michael Integrity Check (MIC) substituiu o CRC32. 11 Novo modo de escolher e utilizar os Vetores de Inicializao. 11 Cada pacote encriptado com uma chave diferente. Para alcanar maior grau de segurana, ainda rodando sobre o hardware desenhado para
o WEP, o novo protocolo batizado de Temporal Key Integrity Protocol (TKIP) incorporou uma srie de mudanas. Em primeiro lugar, o fraco CRC foi substitudo por um novo esquema mais forte chamado de Michael Integrity Check (MIC), mais eficiente na identificao de adulteraes do quadro. O esquema de uso dos vetores de inicializao tambm foi alterado para dificultar a criptoa nlise e o sistema passou a usar chaves temporrias, derivadas da chave original, e diferentes para cada quadro transmitido, o que aumenta muito a segurana do sistema (quanto mais usada uma chave, mais fcil descobri-la).
34
WPA 2
11 O WPA 2 um mecanismo de segurana reconstrudo do zero. 22 No se preocupa com a retrocompatibilidade. 11 Protocolo de criptografia CCMP (em vez do TKIP). 22 Utiliza criptografia de bloco AES (em vez do RC4). 11 Tambm existem o WPA2 Personal e o WPA2 Enterprise. Lanado em 2004, o WPA2 fechou o trabalho do TGi. O WPA2 reconstri o sistema de segurana do Wi-Fi sem nenhuma preocupao com a retrocompatibilidade. Por isso, s suportado por dispositivos fabricados aps 2004. O corao da nova proposta o sistema de criptografia Counter Mode with Cipher Block Chaining Message Authentication Code (CCMP) que, para comear, abandonou o uso da
criptografia de fluxo e do algoritmo RC4, passando a utilizar um algoritmo de criptografia por blocos (block cipher) chamado Advanced Encryption Standard (AES). Apesar do AES ser capaz de utilizar chaves de qualquer tamanho, o padro escolheu chaves de 128 bits. Chaves maiores, apesar de mais seguras, inibiriam a exportao de produtos produzidos nos Estados Unidos, j que esse pas limita a exportao de equipamentos que utilizem criptografia considerada demasiadamente forte. Apesar disso, o algoritmo AES, mesmo utilizando chaves de 128 bits, considerado pelos especialistas como significativamente mais seguro do que o RC4. Assim como o WPA, o WPA2 pode ser usado nas vertentes pessoal (com chaves pr-compartilhadas) e empresarial (utilizando servidor de autenticao RADIUS) nosso prximo assunto.
WPA: Personal versus Enterprise

11 WPA Pessoal. 22 Uso de chaves pr-compartilhadas. 22 Mais fcil de implementar. 11 WPA Empresarial. 22 Uso de servidor de autenticao RADIUS. 22 Cada usurio tem sua senha.
Uma caracterstica do WEP que o WPA ainda preserva o esquema de chaves pr-compartilhadas, considerado no ideal para aplicaes de segurana mais estritas. Mas uma alternativa tambm foi oferecida pelo padro o uso de servidores de autenticao. Um servidor de autenticao recebe pedidos de autenticao dos usurios e os valida ou no. Nesse caso, os usurios tm senhas individuais, alm da chave da rede, provendo uma camada adicional de segurana. Para implementar o servidor de autenticao, o IEEE escolheu uma tecnologia j existente e testada h muito anos, o protocolo Remote Authentication Dial In User Service (RADIUS) , que utilizado para oferecer o servio eduroam.
35
WPA Enterprise: esquema

Rede Sem Fio
Autenticador 1 2 Servidor de Autenticao (RADIUS)
Suplicante Internet 3
Figura 2.20 Esquema de passos para a autenticao WPA Enterprise, com servidor RADIUS.
A Figura 2.20 ilustra o mecanismo de autenticao de usurios suportado por servidor RADIUS, isto , o esquema do WPA Enterprise. Nessa arquitetura, o elemento que deseja se autenticar chamado suplicante. o suplicante que inicia todo o processo logo aps a associao ao ponto de acesso, que, nesse caso, age como o autenticador. O papel do autenticador permitir a conexo do suplicante com o servidor de autenticao e bloquear todo o trfego do suplicante que no seja referente autenticao. Se o servidor de autenticao liberar o acesso, o suplicante poder usufruir de todos os servios da rede. Caso contrrio, ser desassociado pelo ponto de acesso.
IEEE 802.1X e EAP

11 IEEE 802.1X. 22 Padro IEEE para autenticao de usurios. 22 Baseado no Extended Authentication Protocol (EAP). 22 apenas um framework para diversos mtodos.
11 Mtodos EAP. 22 Uso de mtodos legados. 33 TTLS e PEAP. 22 Criptogrficos. 33 TLS. 22 No criptogrficos. 33 MD5 e MSCHAP. O esquema que acabamos de descrever para autenticao de usurios , na verdade, proposto no padro IEEE 802.1X, ou seja, no parte do padro IEEE 802.11 para redes sem fio, sendo tambm usado em outros cenrios. O IEEE 802.1X , por sua vez, baseado no Extended Authentication Protocol (EAP) o que, em termos prticos, significa que ele no descreve o mecanismo de autenticao utilizado e sim um framework para diversos protocolos de autenticao. Esse esquema pode inclusive incorporar novos protocolos que venham a surgir. No EAP, os protocolos disponveis so chamados de mtodos. natural que alguns mtodos sejam considerados mais seguros que outros. Alm disso, alguns mtodos foram, na
36
verdade, concebidos para permitir a utilizao de um sistema de autenticao pr-existente (sistema legado). O objetivo, nesse caso, evitar a duplicao do sistema de autenticao mantido, por exemplo, para a rede cabeada da instituio. Dois mtodos nessa categoria so o Tunneled Transport Layer Security (TTLS) e o Protected EAP (PEAP). Ambos transportam e protegem o mtodo legado de autenticao de usurios. Nesse contexto, o padro se refere ao mtodo legado como mtodo interno. Alm disso, os mtodos EAP podem ou no utilizar criptografia. Os mtodos no criptogr ficos (como o MD5 ou o MSCHAP), devem ser usados em conjunto com outras tcnicas de criptografia ou como mtodos internos do TTLS ou do Peap. Mtodos criptogrficos so evidentemente mais seguros. Nessa classe, o exemplo mais difundido o Transport Layer Security (TLS). Os mtodos de autenticao sero estudados no prximo captulo.
Robust Security Network (RSN)

11 Implementao completa do IEEE 802.11i. 22 Sem suporte a WEP. 33 Com servidor de autenticao. 11 Tambm descreve os mecanismos de gerncia de chaves (que no fazem parte do padro).
Todos esses mecanismos de segurana descritos culminam na implementao considerada ideal de segurana, chamada Robust Security Network (RSN). O RSN um nome curto para designar uma rede que implementa completamente o padro IEEE 802.11i e no prov suporte a WEP. O RSN utiliza WPA (TKIP ou CCMP) com autenticao baseada em um servidor RADIUS. Alm disso, uma RSN deve implementar uma srie de mecanismos de gerncia de chaves criptogrficas (gerao e distribuio) que esto fora do escopo do IEEE 802.11.
Recomendaes de segurana
Para as redes corporativas WPA2 Enterprise. 11 CCMP mais seguro que TKIP. 11 Servidor de autenticao garante maior segurana do que as chaves pr-compartilhadas. 11 Uso de mtodos criptogrficos (como o EAP-TTLS e o EAP-TLS). 11 Sistema bem desenhado para gerncia de chaves. 11 Para as redes domsticas: WPA2 Personal com senhas difceis, trocadas com frequncia.
O que seria, portanto, um sistema de segurana ideal para uma rede sem fio, considerando que os recursos necessrios para sua implantao esto disponveis? Esse sistema seria uma rede utilizando CCMP (WPA2) e servidor de autenticao, alm de um mecanismo de autenticao protegido por EAP-TTLS. Mas essa configurao, alm de mais difcil de implementar, implica o uso de um servidor RADIUS. Assim, para o usurio domstico, preciso propor um cenrio mais simples. Esse cenrio, considerado seguro o suficiente para o uso no comercial, seria o emprego de WPA (de preferncia WPA 2), com um cuidado especial dedicado s senhas pr-compartilhadas (que sejam complicadas e trocadas com frequncia).
37
Requisitos eduroam
11 Suporte autenticao robusta. 22 Servidor RADIUS. 22 IEEE 802.1X. 22 IEEE 802.11i. 11 Comumente chamado WPA2 Enterprise. 11 Essas funcionalidades so encontradas em parte considervel dos APs consumer grade.
Para poder ser utilizado no eduroam, um ponto de acesso tem de suportar os padres IEEE 802.1X e IEEE 802.11i (WPA2 Enterprise). Felizmente, boa parte dos pontos de acesso, mesmo os consumer grade, suportam esses padres.
Atividade Prtica 1 e Configurar AP para autenticar em servidor RADIUS

Resumo dos dados utilizados nesta atividade prtica Senha compartilhada entre AP e FreeRADIUS. SSID Tipo de segurana no ponto de acesso. eduroam123 eduroamXX (exemplo: para IP 10.88.193.137 = eduroam137) WPA2 Enterprise/AES
Ponto de Acesso
Usurio
Servidor RADIUS Instituio 1
Figura 2.21 Prtica de configurao do ponto de acesso para acesso ao servidor RADIUS existente.
As prticas visam preparar cada aluno para instalar e manter o servio eduroam em uma instituio de ensino e pesquisa. A Figura 2.21 mostra como feita a configurao de um ponto de acesso para que o pedido de autenticao seja tratado no servidor RADIUS. Esta prtica mostra tambm as configuraes necessrias no servidor RADIUS para aceitar pedidos de autenticao de um determinado ponto de acesso.
Cadastrando o AP no servidor RADIUS

Para permitir que um servidor RADIUS aceite requisies de autenticao de um ponto de acesso especfico, necessrio cadastrar o ponto de acesso na lista de possveis clientes do servidor RADIUS. Nesta prtica, este passo ser realizado pelo professor em um servidor FreeRADIUS previamente criado. Em prtica realizada adiante, o aluno ir configurar o servidor RADIUS. Considerando o uso do software FreeRADIUS, a seguir podemos visualizar as linhas que devero ser includas no arquivo /etc/freeradius/clients.conf do servidor RADIUS, devendo
38
conter, portanto, o IP do ponto de acesso, a senha compartilhada e configurada no ponto de acesso, assim como seu nome. Nas prticas futuras o aluno sempre ter que configurar informaes dos dispositivos NAS (por exemplo ponto de acesso) no arquivo clients.conf.
client 192.168.0.3 { secret shortname nastype }

A seguir apresentado como feita a configurao de um ponto de acesso com o firmware baseado em Linux DD-WRT.
= eduroam123 = eduroam-uff-1 = other
Configurando roteador com DD-WRT

Como primeiro passo temos a identificao do IP, que ser aquele cadastrado no arquivo clientes.conf citado anteriormente. Perceba que o IP a ser informado ao professor para liberao no FreeRADIUS aquele referente porta WAN.
Figura 2.22 Identificao do IP do ponto de acesso.
O segundo passo compreende a alterao do SSID da rede, ou seja, o nome que ser divulgado aos clientes para se conectarem. Na configurao em laboratrio usaremos algo como eduroamXX, onde XX pode representar o valor decimal do ltimo byte do endereo IP do ponto de acesso. Por exemplo, para um IP 10.88.193.137 o SSID ficaria eduroam137. Lembrando que esta configurao visa somente a diferenciao dos pontos de acesso no laboratrio, na rede de uma instituio real, o SSID deve sempre ser divulgado como eduroam (usando letras minsculas), a fim de garantir a transparncia no acesso dos usurios. Portanto, para a configurao do SSID, deve-se seguir os passos indicados na Figura 2.22, clicando primeiramente na aba Wireless, depois em Basic Settings, logo depois preenchendo o campo SSID e salvando sua configurao com a Apply Settings e Save.
39
Figura 2.23 Configurao do SSID a ser utilizado pelo ponto de acesso.
Finalizando a configurao do ponto de acesso para a autenticao dos clientes no servidor RADIUS pr-existente, temos o apontamento do endereo do IP do servidor RADIUS do professor e a seleo do tipo de segurana suportado pelo ponto de acesso. Como padro do projeto, estaremos utilizando o suporte ao 802.1X por meio do WPA2 Enterprise como modo de segurana e o algoritmo de segurana AES. Caso o modo de segurana ou o algoritmo de segurana esteja selecionado de forma diferente no ponto de acesso e no suplicante (veremos a configurao dos suplicantes em um captulo mais frente), a rede ser exibida como indisponvel para o usurio, impossibilitando a conexo. Sendo assim, atente para a utilizao do WPA2 Enterprise/AES. Navegando pelas abas Wireless e Wireless Security chegamos ao ponto de configurao,
onde deve-se selecionar o modo de segurana como WPA2 Enterprise e o algoritmo WPA como AES. Feito isso, necessrio informar o endereo IP do servidor de autenticao RADIUS (IP do servidor do professor). Devemos tambm informar a chave compartilhada entre o ponto de acesso e o servidor RADIUS, senha esta cadastrada pelo professor no arquivo /etc/freeradius/clients.conf (neste tutorial eduroam123).
40
Figura 2.24 Configurao da comunicao entre o AP e o servidor RADIUS.
Configurando o roteador sem fio Linksys WRT54G

Para conectar ao seu ponto de acesso roteado, utilize Dynamic Host Configuration Protocol (DHCP) em sua mquina cliente, e aps adquirido o IP, acesse o endereo 192.168.1.1 pelo seu navegador. Para que o sistema funcione da maneira almejada, o ponto de acesso sem fio tambm deve ser configurado de forma que encaminhe as requisies para o servidor de autenticao. A opo que permite tal configurao est em Wireless/Wireless Security, como na Figura 2.24.
Figura 2.25 Habilitando a segurana do ponto de acesso.
Em Security Mode, selecionaremos WPA2 Enterprise. Isso indica que utilizaremos uma infraestrutura de acesso baseada em WPA2 no ambiente sem fio, mas em vez de utilizarmos uma nica senha para todos os clientes, iremos nos valer de um servidor de autenticao RADIUS. Isso nos prov uma srie de recursos adicionais, como a possibilidade de defi nirmos uma senha diferente para cada cliente. Uma vez selecionada essa opo, outras aparecero, como na Figura 2.25.
41
Em WPA Algorithms, selecionaremos AES, que nada mais do que um algoritmo de criptografia simtrica que ser utilizado para proteger as informaes trocadas entre o ponto de acesso e o servidor. No RADIUS Server Address colocaremos o endereo IP do servidor RADIUS, que para aonde o ponto de acesso encaminhar as requisies feitas pelos clientes. Em RADIUS Port, colocaremos a porta pela qual o servidor RADIUS estar ouvindo as requisies. Em Shared Key, colocaremos a chave simtrica que o ponto de acesso utilizar para se comunicar com o servidor RADIUS. O campo Key Renewall Timeout no precisa ser alterado. Com isso, encerra-se a etapa de configuraes propostas neste captulo. Atravs delas, possvel realizar autenticao e autorizao, por intermdio do servidor RADIUS e com consulta a uma base de dados LDAP, ou seja, utilizando as configuraes propostas no servio eduroam. Agora, cada usurio pode acessar a infraestrutura de rede sem fio com o login e senha cadastrados na base LDAP. Como primeiro mtodo de autenticao ser utilizado o
Figura 2.26 Configurando a comunicao entre o AP e o servidor RADIUS.
EAP-TTLS e, como segundo mtodo, ser utilizado o PAP. Esses mtodos sero detalhados no prximo captulo.
42
3
Mtodos de autenticao
objetivos
Conhecer os mecanismos de autenticao disponveis para redes IEEE 802.11, suas diferenas e riscos associados. Compreender a autenticao utilizada no eduroam.
conceitos
Autenticao em redes sem fio. Emenda IEEE 802.11i e padro IEEE 802.1X. Mtodos EAP. Mtodos internos e externos. Mtodos criptogrficos e no criptogrficos.
Introduo
Em redes sem fio, a necessidade de mecanismos robustos de autenticao ainda maior do que em redes cabeadas. Isso ocorre porque o acesso fsico a uma rede sem fio se d pelo simples posicionamento (de um possvel agressor) na rea de cobertura da rede. Em seu estgio inicial, o emprego das redes sem fio foi marcado pela insegurana dos mecanismos bsicos de autenticao e privacidade oferecidos pelo Wired Equivalent Privacy (WEP). Felizmente, essas falhas iniciais foram corrigidas e novos mecanismos, mais seguros, foram incorporados, conforme veremos neste captulo.
Autenticao em redes 802.11

11 Open system: 22 No prov autenticao alguma. 11 WEP Chave compartilhada (PSK): 22 vulnervel. 11 IEEE 802.11i = WPA:
22 Mecanismo recomendado. O processo de autenticao mandatrio previsto no padro IEEE 802.11, chamado open-system authentication (autenticao de sistema aberto) no prov, de fato, nenhum mecanismo real ou seguro de autenticao. Trata-se to somente de uma troca de quadros sem o emprego de qualquer tipo de criptografia. O cliente envia para o ponto de acesso um quadro do tipo gerncia e subtipo autenticao (campos do quadro 802.11), indicando o algoritmo de autenticao 0 (open system sistema aberto). O ponto de acesso, ao receber esse quadro, registra o endereo fsico do cliente como sua identificao e responde com outro quadro de gerncia. O cliente, por sua vez, aceita a resposta do ponto de acesso como legtima e o processo se encerra. Como
Captulo 3 - Mtodos de autenticao
22 Substituto para o WEP.
43
no h garantias de que o endereo fsico (endereo MAC) do cliente seja legtimo (ele pode ser facilmente forjado), no ocorre verificao efetiva da identidade do cliente ou mesmo da rede e, portanto, esse mecanismo no deveria, a rigor, ser chamado de autenticao. J no mecanismo de chaves pr-compartilhadas (Pre-Shared Key PSK), um segredo (a chave criptogrfica) previamente configurado no ponto de acesso e nos clientes. A autenticao passa a ser baseada no conhecimento dessa chave. Nesse caso, o cliente tambm inicia a transao enviando um quadro do tipo gerncia e subtipo autenticao, mas indica o algoritmo de autenticao de cdigo 1 (shared key). Em resposta, o ponto de acesso envia um desafio, um texto que deve ser cifrado pelo cliente com a chave pr-configurada e devolvido ao ponto de acesso. O ponto de acesso, ento, recebe o texto cifrado pelo cliente, que deve ser corretamente descriptografado pela mesma chave, a qual o ponto de acesso tambm conhece. O sucesso indica que o desafio foi cifrado com a chave correta e, por con seguinte, que o cliente legtimo. Novamente, observa-se que a identidade do cliente no efetivamente verificada. A autenticao verifica apenas se este tem em poder uma determi nada informao, a chave. Alm disso, novamente, no realizada qualquer autenticao do ponto de acesso. O processo de autenticao que acabamos de descrever parte do mecanismo Wired Equivalent Privacy (WEP), por sua vez parte das verses iniciais do padro IEEE 802.11. Infelizmente, esse mecanismo falho, j que a chave compartilhada pode ser obtida maliciosamente, bastando que um agressor capture os quadros da transao e se utilize de programas de quebra de senhas obtidos facilmente na internet. Por conta dessa e de outras deficincias do WEP, no apenas ligadas ao problema da autenticao, o padro teve de incorporar novos mecanismos de autenticao. Para esse fim, como dissemos no captulo anterior, foi criada a emenda IEEE 802.11i. Vale a pena relembrar e resumir o que foi dito.
IEEE 802.11i
11 Publicada em 2004. 22 Verso de 2003 deu origem ao WPA1.
22 A verso final deu origem ao WPA2. 11 Incorporado ao padro IEEE 802.11 em 2007. 11 Autenticao baseada no padro IEEE 802.1X. Como vimos, a emenda i, publicada em 2004, foi desenvolvida justamente para sanar as deficincias do WEP. No entanto, dada a debilidade do WEP e a decepo inicial com o padro, uma verso provisria da emenda foi publicada j em 2003 com alteraes compatveis com os equipamentos j fabricados, para combater a crescente descrena na tecnologia WiFi. Essa primeira verso do IEEE 802.11i se convencionou chamar WPA1, enquanto WPA2 serve para designar a implementao final do IEEE 802.11i, que requeria mudanas no hardware dos dispositivos. Por isso, o mecanismo de autenticao do WPA1 tambm baseado na ideia de chaves pr-compartilhadas (PSK). O WPA2 a implementao completa de segurana e recomendada para o uso corporativo. Um aspecto importante que ela permite autenticar usurios em vez de mquinas. preciso reconhecer que os mecanismos de chave pr-compartilhada se tornam inseguros pela reutilizao constante e ocasional exposio da chave (em avisos pblicos ou pela divulgao boca a boca) e pela necessidade de troca constante, cada vez que um membro da equipe deixa a instituio um procedimento raramente executado. Por esses motivos, a autenticao de usurios, como prevista no WPA2, fundamental. Para alcanar esse
44
objetivo, o IEEE 802.11i recomenda o emprego de outra tecnologia pr-existente, o IEEE 802.1X (nesse caso, o X maisculo).
IEEE 802.1X
11 IEEE 802.1X um arcabouo (framework). 22 Adaptao do EAP (criado pelo IETF) (RFC 2284 atualizado na RFC 3748). 11 O EAP um protocolo de arcabouo. A autenticao realizada por um protocolo de extenso o mtodo EAP. 11 Os mtodos podem ser mais ou menos adaptados s necessidades especficas de uma rede. O IEEE 802.1X um arcabouo (framework) de autenticao para as tecnologias de rede da
famlia IEEE 802, cujos membros mais notrios so o padro Ethernet (IEEE 802.3) e o prprio WiFi (IEEE 802.11). Na verdade, o IEEE 802.1X apenas descreve o encapsulamento de um padro pr-existente, o Extensible Authentication Protocol (EAP), sobre os padres IEEE 802. O EAP foi criado pelo Internet Engineering Task Force (IETF), descrito originalmente na RFC 2284, e posteriormente atualizado pela RFC 3748. Inicialmente, o EAP era usado apenas sobre enlaces Point-to-Point Protocol (PPP). Foi justamente o padro IEEE 802.1X que ampliou seu uso para outros tipos de enlaces. Seu uso sobre redes locais, como a Ethernet, muitas vezes chamado EAP Over LAN (EAPOL), enquanto EAP Over Wireless (EAPOW) ocasionalmente usado para designar o uso de EAP em redes sem fio. O EAP no descreve um mecanismo de autenticao. Essa autenticao realizada por um protocolo de extenso chamado de Mtodo EAP. Os mtodos podem ser mais ou menos adaptados s necessidades especficas de uma rede.
Arquitetura IEEE 802.1X

a) EAPOL RADIUS
(PAE) Suplicante b)
(PAE) Autenticador Servidor de Autenticao
EAP 802.1X 802.1 1 802.1X 802.1 1 RADIUS UDP/IP 802.3 RADIUS UDP/IP 802.3
Na arquitetura IEEE 802.1X, chama-se de suplicante o dispositivo que busca autenticao. No caso das redes sem fio, o suplicante o cliente que se associa rede atravs de um ponto de acesso. O ponto de acesso tem a funo de autenticador e seu papel intermediar
Figura 3.1 Comunicao entre o suplicante, o autenticador e o servidor de autenticao RADIUS [Gant, 2002].
mtodo EAP
45
o processo, enviando as informaes do suplicante a um servidor de autenticao, que possui a base de dados de usurios. Entre o suplicante e o autenticador, o protocolo usado o EAP Over LAN (Eapol). Como indicado, muitas vezes usado o termo EAP Over Wireless (Eapow) para destacar o fato de que se est operando sobre uma rede sem fio. Entre o autenticador e o servidor de auten ticao, utilizado o protocolo RADIUS, que ser estudado adiante. Assim, o autenticador, como intermedirio da transao, ser responsvel pela traduo das mensagens EAPOL (ou EAPOW) em mensagens equivalentes do protocolo RADIUS, e vice-versa.
O protocolo EAP
Link layer header
Code 1 Byte ID 1 Byte Length 2 Bytes Data 0+Bytes
Figura 3.2 Formato do quadro EAP.
Methods
TLS
AKA/ SIM
Token card
EAP
Link layers
PPP
802.3
802.11
Figura 3.3 EAP transporta diversos protocolos de autenticao sobre diversos protocolos de camada de enlace.
Como dito, o EAP um protocolo de encapsulamento que pode ser executado sobre qualquer protocolo de enlace. O formato do quadro EAP, encapsulado no quadro da camada de enlace, tem os seguintes campos:
11 Code (cdigo) 1 byte: indica o tipo de pacote EAP e como deve ser interpretado o campo data. Os tipos mais importantes so: 11 Tipo 1: Request (Requisio). 11 Tipo 2: Response (Resposta). 11 Tipo 3: Success (Sucesso). 11 Tipo 4: Failure (Falha). 11 ID 1 byte: identificador para relacionar as requisies e suas respectivas respostas (retransmisses tambm usaro o mesmo ID). 11 Length (comprimento) 2 bytes: nmero de bytes do pacote completo (incluindo Code, ID, Length e Data). 11 Data (dados) zero ou mais bytes: sua interpretao depende do valor do campo Code. Em geral, o campo que transporta os dados necessrios para a autenticao.
46
Transao EAP
11 A transao EAP se inicia logo aps a associao do cliente. 11 Fase inicial: Identidade (Identity). 22 Requisies e respostas. 11 A seguir: negociao do mtodo. 22 Requisies e respostas. 11 Finalizando. 22 Sucesso ou falha.
A maior parte das trocas de quadros em uma transao EAP se d atravs de quadros com os cdigos 1: requisio (request) e 2: resposta (response). Nesses quadros, o campo Data subdivido em tipo (type), de 1 byte, e dados do tipo (type data), de comprimento varivel. Vejamos os tipos importantes. O tipo 1, identidade (que no deve ser confundido com o campo ID), geralmente utilizado para iniciar o processo de autenticao. Um quadro Request/Identity (cdigo 1/tipo 1) enviado pelo autenticador e serve para solicitar ao suplicante algum tipo de identidade, que pode ser, por exemplo, um simples nome de usurio (username) ou um elemento mais completo, como um identificador do tipo usurio@domnio (ao estilo de um endereo de e-mail) ou, no caso da autenticao em sistema Microsoft, de um identificador do tipo Domnio/usurio. Em resposta, o cliente deve fornecer essa identidade em um quadro Response/Identity (cdigo 2/tipo 1). Aps essa troca inicial, preciso selecionar um mecanismo de autenticao. Na fase de negociao do mtodo, o autenticador enviar uma requisio especificando, no campo Tipo, um determinado mtodo EAP. Os mtodos EAP correspondem aos tipos 4 em diante. Alguns tipos so especificados a seguir: 11 Tipo 13: EAP = TLS. 11 Tipo 21: EAP = TTLS. 11 Tipo 25: EAP = PEAP. 11 Tipo 29: EAP = MSCHAPv2. 11 Tipo 3: NAK usado para informar ao autenticador que o mtodo solicitado no suportado. Outro tipo importante o tipo 3, NAK. Este usado pelo suplicante quando o autenticador solicita um mtodo no suportado. Nesse caso, o autenticador pode oferecer um mtodo alternativo, enviando outra requisio com o tipo correspondente do novo mtodo, ou recusar o cliente.
A transao EAP encerrada pelo autenticador, que enviar um quadro com o cdigo Sucesso (Success, cdigo 3) ou Falha (Fail, cdigo 4).
47
Exemplo de transao EAP
Suplicante
Autenticador
Radius
RADIUS
1:Association Request Association Response
EAPOL
2:EAPOL-Start
3:Request/Identity
4:Response/Identity
Radius-Access-Request
EAP-Request/Method
5:Radius-Access-Challenge
6:EAP-Response/Method

Radius-Access-Challenge
EAP-Request/Method
EAP-Response/Method
EAP-Success
7:Radius-Access-Acept
8:EAPOL-Key
9:DATA
Figura 3.4 Negociao entre suplicante, autenticador e servidor RADIUS do incio ao fim de uma sesso [Gast, 2002].
10:EAPOL-Logo
48
Vejamos o passo a passo de uma transao EAP, conforme exemplificado na Figura 3.4:
1. Antes da fase EAP se iniciar, o cliente (suplicante) se associa ao ponto de acesso
(autenticador) normalmente, atravs dos quadros de associao do padro IEEE 802.11 (Association Request/Association Response).
2. A transao EAP se inicia propriamente com o envio, pelo suplicante, de uma mensagem
EAPOL-Start. Esse passo omitido em algumas implementaes de suplicante.

3. O Autenticador solicita que o suplicante fornea uma identidade. 4. O suplicante responde com uma identidade, que ser encaminhada pelo AP (autenti-
cador) dentro de um quadro RADIUS-Access-Request a um servidor de autenticao RADIUS (previamente configurado no ponto de acesso).
5. O servidor RADIUS envia, em resposta, um quadro Radius-Access-Challenge, que ser tra-
duzido pelo autenticador em um quadro EAP-Request-Method e enviado ao suplicante. O mtodo a ser usado determinado pelo servidor Radius.
6. Nessa fase, h uma srie de trocas de quadros, que serviro para a autenticao pro-
priamente dita. Em alguns casos, essa etapa pode incluir mais de dez trocas. Em todos os casos, o autenticador realiza a traduo entre os protocolos EAP e RADIUS, intermediando a comunicao. Como dito, possvel que o cliente, ao ser informado dos mtodos escolhidos pelo servidor RADIUS, responda com um quadro EAP-NAK, indicando sua incapacidade de prosseguir com o mtodo. Caber ao servidor RADIUS decidir se um mtodo alternativo ser oferecido ou se a autenticao ser negada.
7. Aps a verificao das credenciais, o servidor RADIUS indica sua aceitao, atravs de um
quadro RADIUS-Access-Accept, traduzido pelo autenticador para um quadro EAP-Success, que enviado ao suplicante.
8. A seguir, o ponto de acesso distribuir uma chave ao suplicante, que ser usada para
criptografar a conexo sem fio desse ponto em diante.

9. Nesse momento, se inicia o uso efetivo da rede, por parte do cliente. Comumente essa
fase comea com a configurao de parmetros de rede, como endereo IP (atravs do protocolo Dynamic Host Configuration Protocol DHCP) e segue para as aplicaes de rede, que motivaram o usurio a buscar a conexo.
10. Quando termina o interesse pelo acesso, o suplicante envia um quadro EAP-Logoff,
desautenticando o usurio.
Mtodos EAP
11 Mtodos criptogrficos. 22 PEAP, TLS e TTLS. 11 Mtodos no criptogrficos. 22 PAP e MsCHAPv2. 11 Esquema misto. 22 Mtodo interno protegido por mtodo externo. Uma das virtudes do EAP sua flexibilidade, ou seja, o fato de oferecer diversos mtodos de
autenticao distintos. Esses mtodos variam em complexidade de implementao e segurana oferecida. Uma importante distino diz respeito ao emprego, ou no, de criptografia para proteo da transao EAP. Ou seja, existem mtodos criptogrficos e mtodos no criptogrficos.
49
Mtodos no criptogrficos so claramente inseguros. No entanto, podem ser usados juntamente com mtodos criptogrficos em um esquema misto, onde o mtodo criptogr fico chamado, nesse contexto, de mtodo de autenticao externo (outer authentication method), protege um mtodo mais simples e possivelmente no criptogrfico, o mtodo de autenticao interno (inner authentication method), como veremos adiante. Os mtodos EAP mais importantes sero estudados a seguir.
TLS (Transport Layer Security)

11 O TLS o sucessor do SSL. 11 Autenticao mtua. 22 Troca de certificados. 11 Infraestrutura de chave pblica (PKI) necessria. 22 Emitir e revogar chaves para usurios. O EAP-TLS foi definido na RFC 5216 e, apesar de pouco utilizado, considerado um dos
mecanismos de autenticao mais seguros para redes sem fio. O protocolo Transport Layer Security (TLS) o sucessor do Secure Socket Layer (SSL), usado para garantir a segurana de transaes na web. O mecanismo prov a autenticao mtua, do cliente e da rede, atravs da troca de certificados. A autenticao dupla garante no apenas a autenticidade do cliente, como tambm a do ponto de acesso, dificultando a incluso de pontos de acesso clandestinos (rogue access points). Por exigir certificados de todos os clientes, o TLS de difcil adoo, exigindo que a instituio crie sua prpria infraestrutura de chave pblica (PKI, do ingls Public Key Infrastructure) para gerar e distribuir os certificados alm de revogar certificados comprometidos. Sua verso tunelada, chamada TTLS, que ser abordada a seguir, simplifica alguns aspectos da adoo do TLS e, por isso, mais amplamente utilizada.
TTLS e PEAP
11 TTLS = tunneled TLS (TLS tunelado). 11 PEAP = Protected EAP. 11 Em ambos, dois mecanismos de autenticao so usados: 22 Mtodo de autenticao externa (outer). 33 Criao de tnel TLS. 22 Mtodo de autenticao interna (inner). 33 Mtodos no criptogrficos podem ser usados. 11 A diferena entre TTLS e PEAP est na forma como o protocolo interno usado.
Para as instituies que j possuem sistemas de autenticao, criados para acesso a contedos e servios da rede cabeada, criar uma segunda infraestrutura de autenticao representaria retrabalho e complicaria as tarefas de administrao. Esse o entendimento que motivou a criao do mecanismo EAP-TTLS. A sigla TTLS significa Tunneled Transport Layer Security (TLS tunelado). O mecanismo funciona em duas etapas. Na primeira, chamada autenticao externa (outer authentication), suplicante e servidor de autenticao estabelecem um tnel TLS. Um certificado usado para autenticar o servidor RADIUS. Na segunda etapa autenticao interna (inner authentication) , um mtodo de autenticao legado utilizado dentro do tnel TLS,
50
para autenticar o usurio. A vantagem agora que apenas so necessrios certificados para o servidor RADIUS, o que reduz drasticamente a quantidade de certificados a administrar. O Protected EAP (PEAP) bastante similar ao TTLS. A diferena est na forma como o protocolo interno operado. No caso do TTLS, o tnel TLS usado para a troca de pares atributo-valor (Attribute Value Pairs AVPs) que sero usados pelo mecanismo de autenticao interno. No PEAP, o tnel usado para iniciar uma segunda transao EAP, que funcionar de forma transparente, isto , sem o conhecimento de que est sendo usada como mecanismo interno. Assim, no EAP-PEAP, o mecanismo de autenticao interna tem de ser um mtodo EAP.
Mtodos de autenticao interna

11 Os mtodos de autenticao interna podem ser no criptogrficos. 22 Operam em um tnel TLS. 11 PAP e MSCHAPv2 so os mais comuns. 22 PAP um dos mtodos pioneiros (usado em enlaces PPP). Login e senha enviados desprotegidos. 22 MSCHAPv2 a segunda verso do mecanismo criado pela Microsoft. Mtodos no criptogrficos seriam inseguros se usados sozinhos, mas como mecanismos
de autenticao interna, gozam da segurana oferecida pelo canal criptogrfico criado pelo tnel TLS. Os dois principais mtodos usados com essa finalidade so o PAP e o MSCHAPv2. O MSCHAPv2 (Microsoft CHAP verso 2) est descrito na RFC 2759. uma atualizao do MSCHAPv1, que possua problemas de segurana. o mecanismo mais comum para os produtos da Microsoft e pode ser usado como mecanismo interno tanto para o TTLS quanto para o PEAP. O Password Authentication Protocol (PAP) foi originalmente criado para uso sobre enlaces PPP, sendo, portanto, um dos mtodos mais antigos e difundidos. Como dito, inseguro, j que transmite login e senha sem qualquer autenticao, e por isso deve ser apenas usado como mecanismo interno de autenticao. A seguir, estudaremos detalhes adicionais do PAP e do MSCHAPv2.
Password Authentication Protocol (PAP)

11 O PAP um protocolo de autenticao simples baseado em senhas. 22 O cliente envia login e senha (Auth-Request). 22 O servidor verifica e autentica ou no (Auth-Ack ou Auth Nack). 11 Autenticao fraca.
O Password Authentication Protocol ou Protocolo de Autenticao de Senhas (PAP) to simples quanto possvel. O cliente inicia a transao atravs de um quadro Authentication-request, que transporta tanto o login quanto a senha do usurio. O servidor, aps a verificao dessas credenciais, responde com um quadro Authentication-ack, caso as credenciais tenham sido aprovadas, ou Authentication-nak, caso contrrio. Como dito, o PAP um mecanismo de autenticao fraco, visto que as informaes dos usurios no so protegidas e podem ser facilmente interceptadas por capturadores de pacotes (sniffers). Por isso, recomenda-se seu uso apenas como mtodo de autenticao interno, caso em que suas transaes so criptografadas pelo tnel TLS.
11 Descrito na RFC 1334 (PPP Authentication Protocols).
51
O PAP um dos dois mtodos descritos na RFC 1334 (protocolos de autenticao para enlaces PPP). O outro o CHAP, no qual o prximo mtodo estudado (MSCHAPv2) foi baseado.
Microsoft Challenge-Handshake Authentication Protocol (MSCHAP)

O MSCHAP existe em duas verses (MSCHAPv1 e MSCHAPv2). 11 A verso 1 obsoleta e no mais suportada. 11 A verso 2 tambm tem vulnerabilidades conhecidas. O MSCHAP a verso da Microsoft para o protocolo Challenge-Handshake Authentication
Protocol (CHAP, tambm proposto na RFC 1334). Sua primeira verso, MSCHAPv1 (RFC 2433), deixou de ser suportada (desde o Windows Vista). A segunda verso, MSCHAPv2 (RFC 2759), foi introduzida pelo Windows NT 4.0 e permanece corrente. Porm, o MSCHAPv2 tem vulnerabilidades conhecidas (Cryptanalysis of Microsofts PPTP Authentication Extensions http://www.schneier.com/paper-pptpv2.pdf) que permitem descobrir as credenciais do usurio, usando poder computacional presente em computadores domsticos. O MSCHAPv2 prov autenticao mtua, atravs do envio de desafios (challenges) nos dois sentidos (para o cliente e para o servidor). 11 Servidor envia um desafio (desafio1) e um id de sesso. 11 Cliente envia resposta contendo: 22 Login. 22 Um desafio (desafio2) para o servidor. 22 Resumo criptogrfico (desafio1 + desafio2 + id + senha usurio). 11 Servidor verifica a resposta do cliente e envia: 22 Indicador de sucesso ou de falha. 22 Resumo criptogrfico (desafio1 + desafio2 + resposta do cliente + senha do usurio). 11 Cliente verifica a resposta de autenticao.
PAP e MSCHAPv2 disponibilidade atual

Windows MSCHAP v2 PAP Nativo No (SecureW2) Linux Nativo Nativo iOS Nativo No (MobileConfig) Android Nativo Nativo
Tabela 3.1 Suporte aos mtodos EAP PAP e MsCHAPv2.
A Tabela 3.1 apresenta a disponibilidade (suporte) aos mtodos PAP e MSCHAPv2, em diversos sistemas operacionais populares. Alm do Linux e do Windows, so apresentados os sistemas para celulares e tablets, iOS e Android. Nota-se que, enquanto o mtodo MSCHAPv2 amplamente suportado, o mtodo PAP no nativo na plataforma Windows e nos iPhones/ iPads. Para o primeiro, necessrio fazer o download de software adicional. Um exemplo o aplicativo SecureW2 (verso de avaliao disponvel em http://www.securew2.com). No caso do iOS, a soluo baixar o MobileConfig, da AppStore. Mas a disponibilidade desses mtodos pode mudar rapidamente, com o surgimento e popularizao de novos sistemas operacionais.
52
Outros mtodos (menos usados)

So muitos os mtodos de autenticao EAP. No entanto, poucos so realmente populares. Alm dos citados at agora, merecem destaque os seguintes mtodos: 11 EAP-LEAP: mtodo proprietrio da Cisco Systems, consiste de uma verso reforada do MSCHAP. O fabricante s recomenda seu uso em ambientes onde as senhas sejam cuidadosamente selecionadas (senhas fortes, com mistura de nmeros, letras maisculas e minsculas e caracteres especiais). No nativamente suportado pelos sistemas operacionais populares, mas o suporte pode ser instalado. De qualquer maneira, pela reconhecida dificuldade em educar os usurios para que selecionem senhas fortes, o prprio fabricante recomenda outros mtodos. 11 EAP-SIM: suporte aos cartes Mdulo de Identificao do Assinante (SIM), usados em dispositivos mveis desde a tecnologia celular GSM. O protocolo usado prov autenticao mtua e AAA (Authentication, Authorization and Accounting). O mtodo no criptogrfico. No caso da telefonia celular, fica a cargo de cada operadora proteger a transao da forma que julgar adequada. 11 EAP-MD5: prov segurana mnima, atravs do uso de resumos criptogrficos do tipo MD5 (sujeitos a ataques de dicionrio em que o resumo comparado a outros resumos de senhas conhecidas). Alm disso, no prov autenticao do servidor. 11 EAP-GTC: o Generic Token Card o token que comea a se popularizar, medida que so adotados mtodos de certificao para o cidado, como o e-CPF. O mtodo EAP-GTC baseado em desafio. O token responsvel por criptografar o desafio enviado pelo servidor de autenticao. Tokens tambm podem suportar senhas descartveis (one-time passwords), que so usadas apenas uma vez.
Mtodos EAP e eduroam

11 No servio eduroam, cada instituio escolhe seus mtodos de autenticao. 11 A autenticao sempre feita na instituio de origem. 11 A autenticao mista sempre recomendada. 11 Os mtodos externos mais usados so o TTLS e o PEAP. 11 Os mtodos internos mais usados so o PAP e o MSCHAPv2. MSCHAPv2 parece mais seguro que o PAP (pelo uso de desafios). No entanto, ambos so mtodos inseguros e devem ser usados como mtodos internos, apenas. No MSCHAPv2, a forma como as senhas so criptografas para armazenamento na base de dados considerada vulnervel.
Para usurios com acesso a informao privilegiada em uma instituio, recomenda-se o uso de TLS, reforando a autenticao do usurio. Em um sistema de federao, cada instituio participante define de forma autnoma e inde pendente as polticas e tecnologias a serem usadas, contanto que aderentes s especificaes bsicas impostas pela federao. Uma das vantagens da tecnologia escolhida para o eduroam a possibilidade de que cada instituio escolha um esquema de autenticao diferente e que, ainda assim, um usurio visitante possa usar a infraestrutura de conectividade local, visto que o pedido de autenticao tratado pela instituio de origem do visitante. A autenticao mista (com a combinao de um mtodo externo seguro e um interno no to seguro) usual e recomendada tanto para TTLS quanto para PEAP e so solues consideradas seguras.
Atualmente, o MSCHAPv2 suportado por um nmero maior de clientes do que o PAP.
53
Em relao ao mtodo interno, apesar de o protocolo MSCHAPv2, em um primeiro momento, parecer mais seguro que o PAP, o fato que ambos os mtodos so inseguros e devem ser usados apenas como mtodos de autenticao interna. O mtodo MSCHAPv2 o nico mtodo nativo em uma ampla gama de dispositivos como, por exemplo, aqueles executando sistemas operacionais da famlia Windows, mas o armazenamento de suas senhas (protegidas pelo NT hash) considerado inseguro. Uma instituio pode optar por oferecer um ou ambos desses mtodos ou mesmo recorrer a outros (como o Carto de Token Genrico GTC, por exemplo). Alm disso, mtodos diferentes podem ser usados para usurios diferentes. Pode-se desejar, por exemplo, utilizar um mtodo em que o usurio com privilgios tenha de prover um certificado (como o mtodo TLS). O importante que as escolhas de uma instituio no afetam o restante da federao e no implicam incompatibilidade.
Atividade Prtica 2 e Configurar clientes com diferentes mtodos de autenticao

Resumo dos dados utilizados nesta atividade prtica Usurio para autenticao com suplicantes. Senha para autenticao com suplicantes. Combinao de mtodos EAP (externo/interno). Professor ir fornecer (algo como teste). Professor ir fornecer (algo como teste123). TTLS/PAP PEAP/MSCHAPv2
Ponto de Acesso
Usurio
Figura 3.5 Prtica de configurao de clientes para acesso a partir de diversos dispositivos.
A segunda prtica tem como objetivo configurar diferentes dispositivos como clientes do servio eduroam. Sero demonstradas configuraes nos sistemas operacionais Windows, Linux e Android. Dependendo do sistema operacional e dos mtodos de autenticao utilizados, softwares adicionais podem ser necessrios para permitir a configurao do dispositivo cliente.
Configurao de dispositivos para TTLS/PAP

Configuraes para Android
1. Para conectar-se rede eduroam utilizando TTLS/PAP, primeiro entre no menu de
Configuraes/Settings.
2. No menu de configuraes, entre emConexes sem fio e rede (Figura 3.6a). 3. Uma vez acessada a opoConexes sem fio e rede,v paraConfiguraes Wi-Fi (Figura 3.6b)
54
4. NasConfiguraes Wi-Fi,selecione a redeeduroam (Figura 3.6c).
Figura 3.6 Configurao do cliente Android (a), (b) e (c).
5. Ser aberta uma nova janela, assim como na Figura 3.7a. O mtodo EAP de primeira fase
ser TTLS, e o de segunda fase,PAP (no selecione certificados ou credenciais).

6. Por fim, insira no campoIdentidadeseu usurio@domniodainstituio. No campo Senha,
insira sua senha e deixe o campoIdentidade Annimaem branco (Figura 3.7b).
Figura 3.7 Configurao do cliente Android (a) e (b).
Configuraes para Windows

Para a configurao do cliente Windows, ser necessria a utilizao de um software de terceiros (SecureW2), uma vez que o Windows no suporta nativamente o mtodo TTLS. Siga os passos a seguir para a instalao e configurao do suporte ao TTLS/PAP para Windows.
1. Download do SecureW2 [SecureW2, 2012].
55
Passos para a instalao do SecureW2

1. Clique emNexte aceite o acordo (Figura 3.8a). 2. Certifique-se de que o componenteTTLSest marcado e termine a instalao (Figura 3.8b).
3. Em Iniciar, clique emPainel de Controle/Rede e Internet/Centro de Rede e Compartilhamento.
Clique emGerenciar Redes Sem Fio. Clique com o boto direito na redeeduroame em seguida emPropriedades (Figura 3.9a).
4. Na aba Segurana, escolha o Tipo de Seguranacomo WPA2-Enterprise, e Tipo de Criptografia,
Figura 3.8 Instalao do SecureW2 (a) e (b).
AES. Selecione tambm, como mtodo de autenticao, oSecureW2 EAP-TTLSe desmarque as demais caixas. Clique emConfiguraese siga para o prximo passo (Figura 3.9b).
5. Clique emNewpara criar um novo perfil ou emConfigurepara editar o perfil Default
(Figura 3.10a).
6. Na abaCertificates, desmarque a caixaVerify Server certificate (Figura 3.10b). 7. Na abaAuthentication, selecione o mtodoPAPe clique em OK (Figura 3.10c).
Figura 3.9 Finalizao da instalao do SecureW2 (a) e configurao do Windows (b).
56
Figura 3.10 Configurao do SecureW2 (a), (b) e (c).
8. Na abaUser accountdesmarque a opoPrompt user for credentials, coloque seu nome
de usurio, sua senha e o domnio (e.g. uff.br) (Figura 3.11a).

9. No mesmo menuTarefas,noCentro de Redes e Compartilhamento, clique emConectar-se a
uma rede. Clique emeduroame em seguida emConectar (Figura 3.11b).
Figura 3.11 Finalizao da configurao do SecureW2 (a) e conectando ao eduroam (b).
Configuraes para Linux (Ubuntu)

O Linux j oferece suporte ao TTLS e PAP de forma nativa, suprimindo a necessidade de instalao de um software suplicante de terceiros.
1. Selecione a redeeduroamnas redes sem fio. 2. Configure a rede como wireless security:WPA & WPA2 Enterprise;em Authentication,escolha
Tuneled TLS; j emInner Authentication,escolha PAP.Nos campos de usurio e senha, utilize seu usurio@instituio.bre a senha equivalente (Figura 3.12a).
3. Caso aparea um alerta de certificado, ignore-o (Figura 3.12b).
57
Figura 3.12 Configurao do Linux para TTLS/ PAP (a) e (b).
Configurao de dispositivos para PEAP/MSCHAPv2

Em geral, os dispositivos sem fio tm suporte nativo aos mtodos PEAP e MSCHAPv2, porm, comum a necessidade de uma configurao adicional para a no verificao dos certificados autoassinados (no validados por uma CA real) no estabelecimento da conexo. Portanto, caso seja utilizado um certificado gerado localmente no servidor RADIUS para estabelecimento das conexes PEAP (e tambm TTLS), ser necessrio suprimir a verifi cao da validade desse certificado.
Configuraes para Android

1. Para conectar-se rede eduroam utilizando PEAP/MSCHAPv2, primeiro entre no menu de
Configuraes/Settings.
2. No menu de Configuraes, entre emConexes sem fio e rede (Figura 3.13a). 3. Uma vez acessada a opoConexes sem fio e rede,v paraConfiguraes Wi-Fi
(Figura 3.13b).
4. NasConfiguraes Wi-Fi,selecione a redeeduroam (Figura 3.13c).
Figura 3.13 Configurao do cliente Android (a), (b) e (c).
5. Ser aberta uma nova janela, assim como na Figura 3.13. O mtodo EAP de primeira fase
ser PEAP, e o de segunda fase,MSCHAPv2 (no selecione certificados ou credenciais).
58
6. Por fim, insira no campoIdentidadeseu usurio@domniodainstituio. No campo Senha,
insira sua senha e deixe o campoIdentidade Annimaem branco (Figura 3.14).
Figura 3.14 Configurao PEAP/MSCHAv2 para Android.
Configuraes para Windows XP

1. V ao menu Iniciar/Painel de Controle (Figura 3.15a). 2. Escolha a opo Conexes de Rede (Figura 3.15b).
a opo Propriedades (Figura 3.16a).

4. Escolha a opo Redes sem fio no menu do lado esquerdo (Figura 3.16b). 5. Escolha a opo Adicionar (Figura 3.16c).
Figura 3.15 Configurao do PEAP/MSCHAPv2 para Windows XP (a) e (b).
3. Clique com o boto direito do mouse em cima da conexo de rede sem fio e escolha
59
6. Digite as informaes da rede sem fio para autenticao de rede, como WPA2, e cripto -
grafia, como AES, conforme a Figura 3.17a.

7. V at a aba Autenticao (Figura 3.17b). 8. Altere o tipo de EAP como na figura a seguir e escolha Propriedades (Figura 3.17c).
Figura 3.16 Configurao do Windows XP (a) e adio de uma nova rede (b) e (c).
9. Desmarque a opo Validar certificado do servidor e, em seguida, escolha a opo
Configurar (Figura 3.18a).

10. Desmarque a opo Usar automaticamente meu nome... Em seguida, escolha OK em todas
as telas restantes.
11. J possvel conectar-se informando seu usurio@instituio.br e senha (Figura 3.18c).
Figura 3.17 Configurando o mtodo de autenticao PEAP/MSCHAv2 para o Windows XP (a), (b) e (c).
60
Figura 3.18 Finalizando a configurao do Windows XP, retirando a validao de certificados (a), (b) e (c).
61
62
4
RADIUS Viso geral e conceitos fundamentais
objetivos
Conhecer os conceitos mais importantes de um sistema de autenticao baseado no padro RADIUS, compreendendo seu papel fundamental para o servio eduroam. Adquirir conhecimentos bsicos sobre a instalao e configurao essencial do RADIUS para operar no contexto do eduroam.
conceitos
Componentes da arquitetura cliente-servidor do RADIUS. NAS, suplicante e servidor de autenticao. O conceito de AAA: Authentication, Authorization and Accounting (Autenticao, Autorizao e Contabilizao).
Introduo
11 O Remote Authentication Dial in User Services (RADIUS) segue o paradigma cliente-servidor. 11 Os componentes de sua arquitetura so: 22 Cliente RADIUS: envia ao servidor as credenciais do usurio. 22 Servidor RADIUS: verifica essas credenciais. 11 Foi criado primeiramente apenas para autenticao e foi posteriormente estendido para Autorizao e Accounting (AAA). O Remote Authentication Dial In User Service (RADIUS) um padro IETF que oferece
servio de Autenticao, Autorizao e Auditoria (AAA), consolidado no mercado como uma soluo robusta para diversos servios de autenticao. Desenvolvido no incio da dcada de 90 e sendo continuamente incrementado, o RADIUS ainda consegue satisfazer os requisitos das tecnologias emergentes. O servidor RADIUS, em conjunto com a infraestrutura IEEE 802.11i, um dos mtodos mais seguros para controle de acesso s redes sem fio. O RADIUS foi proposto originalmente pela RFC 2058, seguida de diversas revises (RFCs 2138, 2865). O servio de accounting foi proposto em RFC separada [RFC 2866]. O RADIUS utilizado para prover um servio de autenticao centralizada em diversos tipos de rede de acesso, tais como as que utilizam modems Digital Subscriber Line (DSL), dial-up, Virtual Private Networks (VPNs), redes sem fio ou cabeadas.
Captulo 4 - RADIUS Viso geral e conceitos fundamentais
63
O servio adota o modelo cliente-servidor. O cliente RADIUS responsvel por obter a informao sobre o cliente final e repass-la para o servidor RADIUS, alm de interpretar a resposta, dando ou no acesso ao cliente.
Cliente RADIUS
O cliente RADIUS um intermedirio entre o usurio que busca autenticao e o servidor. 11 Para acesso remoto (modem DSL ou dial-up): o cliente o NAS ou RAS. 11 Em VPNs, o cliente o VPN Server. 11 O cliente pode estar embarcado em switches. 11 No eduroam, o cliente o ponto de acesso (tambm usado o termo NAS). O cliente RADIUS , tipicamente, um intermedirio entre o dispositivo do usurio final e o servidor. O tipo de cliente depender, portanto, do tipo de rede sendo utilizado. Em redes
de acesso remoto, onde o usurio se conecta por intermdio de modems dial-up ou DSL, o cliente ser um Network Access Server (NAS), s vezes chamado de Remote Access Server (RAS). Em redes virtuais privadas (VPNs), o prprio servidor VPN pode ser um cliente RADIUS e, em alguns casos, um switch pode exercer esse papel. Como veremos, em redes sem fio, convencionou-se usar tambm o termo NAS para se referir ao cliente RADIUS, que ser o ponto de acesso.
Servidor RADIUS
O servidor RADIUS recebe e verifica as credenciais do usurio. As credenciais podem estar armazenadas em: 11 Bancos de dados SQL. 11 Diretrios LDAP. 11 Em um arquivo texto local. O servidor RADIUS responsvel por receber pedidos de conexo, autenticar o usurio e repassar ao cliente RADIUS as informaes necessrias para este dar acesso rede ao
usurio. As credenciais do usurio so verificadas contra uma base de dados que pode ser mantida localmente, sob a forma de um arquivo texto, ou em um elemento externo, como uma base de dados SQL ou LDAP.
Servios oferecidos pelo RADIUS

O RADIUS oferece o servio AAA: 11 Autenticao (Authentication): verificar a autenticidade de usurios, atravs da checagem de suas credenciais (login e senha, certificados digitais, biometria etc.). 11 Autorizao (Authorization): determinar os privilgios de um usurio autenticado. 11 Contabilidade (Accounting): quantificar e registrar o uso de recursos por parte dos usurios. O RADIUS foi proposto originalmente para autenticao em redes Point-to-Point Protocol (PPP) e posteriormente estendido para oferecer mecanismos de autorizao e tambm accounting. Alm disso, tambm passou a oferecer esse servio em outros tipos de rede.
64
RADIUS e EAP
802.1X
Figura 4.1 Esquema 802.1X de encaminhamento de autenticao de um cliente at o servidor RADIUS.
Suplicante
EAP sobre L2 (EAPOL)
Autenticador
EAP sob RADIUS
Servidor RADIUS
BD
Em redes locais, o padro RADIUS pode ser utilizado em conjunto com o padro Extensible Authentication Protocol (EAP). Como comentado anteriormente, o padro IEEE 802.1X descreve o encapsulamento do EAP sobre os padres IEEE 802. Nesse cenrio, destacamos os trs componentes principais do servio de autenticao, o cliente final ou suplicante (quando utilizados mtodos EAP), o NAS (cliente RADIUS) com suporte ao 802.1X para prover o encaminhamento e controle de acesso do cliente e, finalmente, o servidor RADIUS, que verificar e responder ao NAS a cada requisio de autenticao. Na prtica, o NAS implementado por um ponto de acesso IEEE 802.11 ou switch IEEE 802.3, por exemplo.
RADIUS e IEEE 802.11
Figura 4.2 Demonstrao da localizao do NAS (como AP).
Suplicantes
AP (NAS)
Servidor RADIUS
Em uma rede local sem fio, os elementos da arquitetura EAP/IEEE 802.1X tomam a forma representada na Figura 4.2. O suplicante o dispositivo mvel do usurio, o NAS o ponto de acesso (AP) e o servidor RADIUS um computador acessado pelo AP (NAS) atravs da rede cabeada.
NAS
O NAS exerce papel importante na comunicao entre suplicante e servidor RADIUS: 11 Encaminha requisies do suplicante ao RADIUS. 11 responsvel pela coleta de informaes para accounting. 11 Utiliza IEEE 802.1X (acesso baseado em portas). Porta Controlada
q
Suplicante 1
Figura 4.3 Demonstrao da porta controlada e no controlada no 802.1X [Nakhjiri, 2005].
Porta no Controlada Autenticador servidor RADIUS
Suplicante N
65
Como dissemos, o Network Access Server (NAS) o principal comunicador entre o suplicante e o servidor RADIUS. Seu nico papel o de encaminhar pedidos gerados pelo cliente e liberar ou no o acesso rede. Quando utilizado accounting, o NAS o responsvel por coletar e enviar as informaes necessrias ao servidor RADIUS. Utiliza o padro 802.1X, que realiza o controle de acesso baseado em portas e, como tal, inicialmente recebe e encaminha pacotes por uma porta no controlada. Conforme a resposta do servidor RADIUS, libera uma porta ao cliente (porta controlada) para acesso rede (e outros servios, como DHCP) ou no.
Suplicante
O suplicante executado na mquina do usurio: 11 Requisita acesso ao NAS. 11 NAS encaminha pedido ao servidor RADIUS. 11 Deve suportar mtodos EAP. 22 PAP, CHAP, MSCHAP, ou seja, suplicantes so os softwares que do suporte aos mtodos EAP.
O suplicante o componente de software executado no dispositivo do usurio final. ele que envia os dados do usurio ao NAS, que, por sua vez, os reencaminha ao servidor RADIUS. Assim, o suplicante deve suportar diversos mtodos EAP. Os mtodos mais utilizados so: PAP, CHAP, MSCHAPv2 etc. Caso seja exigido pelo servidor RADIUS um mtodo no suportado pelo suplicante em questo, o cliente ser incapaz de se autenticar.
RADIUS e eduroam
eduroam
AL
EU
.br
.pe
.pt
.uk
Figura 4.4 Exemplo de demonstrao da hierarquia do eduroam mundial ligando Amrica Latina e Europa.
Uma caracterstica importante do RADIUS permitir a criao de uma estrutura distribuda e hierrquica de autenticao. Essa funcionalidade o requisito fundamental para a criao de um servio federado como o eduroam. Voltaremos ao tema da montagem de uma federao com RADIUS e ao servio de roaming no Captulo 6.
O protocolo RADIUS
O protocolo RADIUS transportado sobre UDP. Portas utilizadas: 11 1812 para autenticao 11 1813 para contabilizao.
66
Alguns servidores usam as portas no padronizadas 1654 e 1646 (respectivamente). Para comunicao entre autenticador e servidor usado um segredo compartilhado. O protocolo RADIUS envia suas mensagens encapsuladas sobre o protocolo de transporte UDP e utiliza as portas padronizadas 1812 e 1813 (esta apenas para accounting). As credenciais dos usurios so protegidas por uma senha compartilhada entre o autenticador (NAS) e o servidor RADIUS. O restante da mensagem, no entanto, enviado em texto plano.
Essa soluo no oferece grau elevado de segurana e, em muitos casos, recomenda-se a adoo de mecanismos adicionais (como proteo da comunicao atravs de IPSec) ou do uso da verso criptogrfica do protocolo RADIUS, chamada RadSec, que ser assunto do Captulo 7.
Formato da mensagem RADIUS

0 Code 7 Identier 15 Length 31
Authenticator
Figura 4.5 Formato da mensagem RADIUS.
Attribute Uma mensagem RADIUS encapsulada no campo de dados UDP, indicando a porta de destino usada pelo servidor. Como vimos, esta frequentemente a porta 1812. Algumas verses utilizaram a porta 1645, mas as implementaes mais populares, como FreeRADIUS e Radiator utilizam a porta oficial 1812. O formato dos dados enviados pelo protocolo RADIUS segue o formato da mensagem descrito a seguir, sendo que os campos so enviados na ordem da direita para a esquerda.
Tipos de mensagens RADIUS

Os tipos so identificados pelo campo Code (1 octeto): 11 1 Access-Request: gerado pelo NAS para encaminhamento da requisio do usurio. 11 2 Access-Accept: enviado do RADIUS ao NAS para liberao de porta (acesso). 11 3 Access-Reject: enviado ao NAS como rejeio de autenticao ou autorizao. 11 4 e 5 Accounting-Request/Response: tratados na seo sobre Accounting. 11 11 Access-Challenge: enviado do RADIUS para o NAS para perguntar ou negociar algo. 11 12 e 13 Status-Server/Client: verifica se ambos esto funcionando. O campo Code formado por um byte e identifica o tipo da mensagem RADIUS. Caso no possua uma identificao conhecida, ocorre o descarte silencioso da mensagem. Utiliza
cdigo em formato decimal. Para exemplificar, a Figura 4.6 mostra uma troca de mensagens entre o autenticador (o cliente RADIUS) e o servidor RADIUS e seus respectivos cdigos.
67
Cliente RADIUS RADIUS: Access-Request (1)
Servidor RADIUS
RADIUS: Access-Accept (2) ou
RADIUS: Access-Reject (3)
RADIUS: Access-Challenge (11)
ou
Figura 4.6 Troca de mensagens RADIUS.
Outros campos das mensagens RADIUS

11 Identifier (1 octeto): auxilia nos pedidos e respostas do servidor RADIUS. Identifica mensagens duplicadas (mesmo IP, porta de origem e ID em um curto perodo de tempo). 11 Length (2 octetos): tamanho do pacote. 11 Authenticator (16 octetos): utilizado para autenticar a resposta requerida pelo servidor RADIUS ou esconder senha. O octeto mais significativo transmitido primeiramente. 11 Atributos: autenticar, autorizar, informar e configurar detalhes para pedidos e respostas entre cliente e servidor. Tipo Tamanho Valor
Figura 4.7 Formato dos campos de atributo.
Alm dos campos identifier (identificador), length (comprimento) e authenticator (autenticador), merecem destaque os campos de atributos, que podem ser vrios. Conforme a Figura 4.7, cada atributo possui os campos tipo tamanho e valor. Os atributos transportam as informaes de autenticao, como nome de usurio e credenciais, alm de outras informaes
teis, como a identificao do NAS e da porta a qual o usurio esta tentando se associar. Uma mesma mensagem pode transportar diversos atributos. A seguir, uma lista de alguns dos principais atributos apresentada
Alguns atributos transportados nas mensagens RADIUS

11 1 User-Name: esse atributo indica o nome de usurio a ser autenticado. Enviado, geralmente, no pacote Access-Request. 11 2 User-Password: atributo referente senha do usurio a ser autenticado. Enviado no pacote Access-Request. 11 3 CHAP-Password: esse atributo indica uma resposta do usurio ao handshake de desafio do CHAP. Enviado no pacote Access-Request quando utilizado esse mtodo EAP. 11 4 NAS-IP-Address: esse atributo indica o IP do NAS que requisitou a autenticao do usurio. Serve como identificador nico de um NAS para o servidor RADIUS e enviado no pacote de Access-Request. 11 5 NAS-Port: utilizado para identificar a porta fsica por onde o usurio est se auten ticando. Essa porta nada tem a ver com as portas TCP ou UDP. Porta de controle do NAS (802.1X), como mostra a Figura 4.3.
68
11 6 Service-Type: esse atributo informa o servio requisitado ou provido pelo servidor RADIUS ao NAS. Por exemplo, um atributo com o campo Administrative informar ao NAS que o usurio tem permisso para acessar a interface administrativa do equipamento. 11 ... 11 32 NAS-Identifier: esse atributo informa o identificador do NAS a ser enviado no Access-Request. Porm, devemos ressaltar que geralmente o NAS-IP-Address o mais utilizado como esse identificador e no tal atributo. 11 33 Proxy-State: o atributo que diz que aquele pacote RADIUS foi redirecionado entre proxies (Access-Request). Cada servidor intermedirio insere seu atributo Proxy-State e o retira quando volta a resposta (Access-Accept, Access-Reject ou Access-Challenge).
Exemplo (parte 1)
11 Usurio nemo deseja acesso. 11 Senha compartilhada (NAS - Servidor): xyzzy5461. 11 Senha do usurio: arctangent. 11 Acesso realizado pela porta 3. 11 Ser enviado um pacote UDP com um pedido de acesso (Access-Request).
Como exemplo, considere a solicitao do usurio nemo para acesso em uma determinada rede. Os dados referentes identificao do usurio, senha compartilhada, senha de usurio e porta so informados na mensagem RADIUS, que ser encapsulada em um pacote UDP.
Figura 4.8 Contedo de uma mensagem Access-Request.
Exemplo (parte 2)
01 98 93 01 00 f4 d4 10 00 22 13 05 38 7a ce 06 0f 01 31 00 40 06 96 00 3f 6e e4 00 94 73 97 80 57 bd 83 d5 cb 65 6d 6f 02 12 0d be 70 8d 3f 78 2a 0a ee 04 06 c0 a8 03
NAS 192.168.1.16
Servidor RADIUS A mensagem RADIUS formada com os campos necessrios e as informaes do usurio. A senha completada com zeros at formar um mltiplo de dezesseis bytes. Em seguida, o Request Authenticator concatenado a ela e depois calculado o hash por MD5. Esse valor, ento, entra em um XOR com os dezesseis primeiros octetos da senha e so guardados nos dezesseis primeiros octetos da string do campo de senha do usurio.
Code=Access-Request ID = 0 Length = 56 Request Authentication: nmero randmico de 16 octetos Atributos: User-Name = nemo User-Password: 16 octets do password completados com zeros e combinados por XOR com o MID5 de (senha compartilhada | Request Authentication) NAS-IP.Address = 192.168.1.16 NAS-Port = 3 Mensagem
69
Caso a senha possua mais do que dezesseis caracteres, o hash recalculado com a concatenao da senha com o resultado do primeiro XOR. Em seguida, esse novo resultado entra em um XOR com os prximos 16 octetos da senha e o resultado final guardado no segundo campo de 16 octetos do campo de string do atributo. Essa operao ser repetida quantas vezes forem necessrias, at o mximo de 128 caracteres.
Exemplo (parte 3): Cliente autenticado e pacote de Access-Accept retornado ao NAS

02 00 00 26 86 fe 22 0e 76 24 ba 2a 10 05 f6 bf 9b 55 e0 b2 06 06 00 00 00 01 0f 06 00 00 00 00 0e 06 c0 a8 01 03
Code = Access-Acept ID = 0 (o mesmo do Access-Request) Length = 38 Response Authenticator: 16 bytes gerado por um MD5 de code + ID + length + Request Authenticator + Atributos da Resposta + senha compartilhada Atributos: Service-Type = Login Login-Service = Telnet Login-IP-Host = 192.168.1.3 Mensagem NAS 192.168.1.16 J a mensagem de sucesso enviada em resposta ao pedido de autenticao do cliente formada principalmente pelo cdigo da resposta, o ID e um checksum carregado no Response Authenticator. Com isso, o NAS libera a porta 3 ao cliente para o acesso. Servidor RADIUS
Figura 4.9 Contedo de uma mensagem de retorno do tipo Access-Accept.
Comandos do FreeRADIUS
Comandos mais comuns: 11 radiusd ou freeradiusd (daemon). 11 radtest (teste de autenticao). 11 radiusd X (modo debug).
radtest -t mschap usurio senha_do_usuario endereo_servidor_Radius:porta_Radius porta NAS senha_compartilhada
Exemplo: ratest t mschap teste teste123 localhost:1812 0 eduroam123

70
Os principais comandos utilizados normalmente por um administrador FreeRADIUS so: freeradius, radiusd e radtest.
Atividade Prtica 3 e Instalao e configurao de um servidor RADIUS

Resumo dos dados utilizados nesta atividade prtica Usurio de teste criado no arquivo users Senha do usurio de teste Senha compartilhada entre o localhost e o RADIUS Arquivos editados Arquivo para liberao do localhost como NAS Arquivo contendo o cadastro do usurio Arquivo de configurao do mtodos EAP externo /etc/freeradius/clientes.conf /etc/freeradius/users /etc/freeradius/eap.conf /etc/freeradius/sites-enabled/inner-tunnel (padro) Arquivo de configurao dos mtodos EAP internos Ou se voc seguiu o tutorial e criou um arquivo novo, chamado eduroam /etc/freeradius/sites-enabled/eduroam A terceira prtica tem como objetivo realizar a instalao e configurao de um servidor RADIUS representando uma instituio de ensino e pesquisa e configurar um ponto de acesso para encaminhar os pedidos de autenticao a esse servidor, tal como ilustrado na Figura 4.10. clientex (exatamente como escrito, no substitua o x) password eduroam123
Ponto de Acesso
Figura 4.10 Prtica de instalao do servidor RADIUS de uma instituio.
Usurio
Instalando o RADIUS
Para implementar o servio RADIUS, utilizaremos nesta prtica o software FreeRADIUS. A instalao do servidor bem simples e demanda poucos comandos.
# sudo apt-get install freeradius
Configurando o RADIUS sem federao

Primeiramente ser configurado um servidor RADIUS capaz de autenticar usurios a partir do /etc/freeradius/users, sem qualquer tipo de consulta base LDAP. Como primeiro passo, editaremos o arquivo /etc/freeradius/clients.conf, para que possamos realizar um teste de autenticao em localhost e em texto plano. O referido arquivo dever conter as seguintes linhas:
71
# Bloco referente ao endereo IP do cliente (AP) client 127.0.0.1 { # senha compartilhada entre o cliente (AP) e o RADIUS secret = eduroam123
# Clientes podem enviar mensagem de autenticao junto com AccessRequest, porm clientes mais antigos no a enviam. Em nosso caso no exigimos mensagem de autenticao vinda do cliente require_message_authenticator = no
# Nome dado ao cliente shortname = localhost
# Opcional, usados para verificar a possibilidade de conexes simultneas pelo mesmo cliente. Localhost no usa NAS. }
No arquivo /etc/freeradius/users, deveremos acrescentar as linhas:
nastype
= other
# Composto por nome do usurio, tipo de password armazenado (texto puro) e uma mensagem de retorno ao cliente caso o usurio seja encontrado. clientex Cleartext-Password := password Reply-Message = Hello, %{User-Name}
Feito isso, podemos iniciar o servidor RADIUS em modo debug com o seguinte comando:
# freeradius -X
Agora, vamos testar a autenticao do usurio. Para isso, vamos executar o autenticador de teste (radtest) para o usurio criado com sua respectiva senha, apontando para o servidor FreeRADIUS na porta padro (1812), indicando a porta do NAS (0 other) e informando a senha compartilhada entre cliente-servidor.
# radtest t pap clientex password localhost:1812 0 eduroam123

Onde clientex e password so os campos editados no arquivo users e eduroam123 refere-se ao campo editado no arquivo clients.conf. A resposta para o cliente de que a conexo foi realizada com sucesso algo como a destacada a seguir:
# Enviando a mensagem de requisio de acesso, com um respective ID ao servidor localhost na porta 1812 Sending Access-Request of id 169 to 127.0.0.1 port 1812 # Atributos passados pelo cliente User-Name = clientex User-Password = password
72
NAS-IP-Address = 127.0.0.1 NAS-Port = 0 # Retorno do servidor RADIUS ao cliente # Sucesso na autenticao rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=169, length=39 Reply-Message = Hello, clientex
Uma vez que configuramos o servidor RADIUS para autenticao de clientes em uma base local com senha em texto plano, seguiremos para uma segunda etapa. Antes de utilizar o LDAP para consulta de usurios, vamos configurao dos mtodos de autenticao, EAP. Primeiramente deveremos configurar o arquivo /etc/freeradius/eap.conf contendo as seguintes informaes:
# Bloco de configurao para os mtodos EAP suportados eap {
# Alteramos o mtodo default de PEAP para TTLS # TTLS (EAP TLS tunelado), pode utilizar apenas de certificados do lado do servidor. Ou seja, TTLS como EAP e mtodo de segunda fase sendo PAP, CHAP, MSCHAPv2 etc, ou ainda TLS (certificado tambm do lado do cliente) se no houver mtodo de segunda fase. #default_eap_type = peap default_eap_type = ttls
# Tempo em que se mantm uma determinada resposta a um EAP-Request timer_expire = 60
# Ignorar tipos de EAP no conhecidos? Por padro, no, mas

poderamos rejeitar ignore_unknown_eap_types = no
# Caso ativado, resolve um bug do Cisco AP1230B cisco_accounting_username_bug = no
# Bloco referente ao TLS tls { certdir = ${confdir}/certs cadir = ${confdir}/certs private_key_password = teste123 private_key_file = ${certdir}/server.key
73
certificate_file = ${certdir}/server.pem CA_file = ${cadir}/ca.pem dh_file = ${certdir}/dh random_file = /dev/urandom fragment_size = 2048 include_length = yes check_crl = no cipher_list = DEFAULT
# Bloco do TTLS ttls {
# Mtodo EAP de segunda fase padro default_eap_type = mschapv2
# Qualquer mensagem trocada que no estaria dentro do tnel copiada para ele copy_request_to_tunnel = yes
# Respostas ao NAS sero dadas com base nos atributos internos ao tnel. Exemplo: responde ao NAS com o usurio verdade e no anonymous.
use_tunneled_reply = yes
# Passado o arquivo de configurao para os mtodos de autorizao, autenticao, accounting etc. } virtual_server = eduroam
# Bloco do PEAP peap { default_eap_type = mschapv2 copy_request_to_tunnel = yes use_tunneled_reply = yes virtual_server = eduroam }
# Bloco mschapv2, caso quisesse utiliz-lo sem PEAP, TTLS etc.
74
mschapv2 { }
Tanto para a utilizao de TTLS ou PEAP referenciado o arquivo /etc/freeradius/sites-enable/eduroam como virtual_server, e nele que deveremos configurar os mtodos de autenticao suportados.
Ateno neste ponto: se voc utilizar o arquivo padro citado pelo FreeRADIUS, teremos a edio e indicao no eap.conf para o arquivo chamado inner-tunnel e no eduroam. Como forma de padronizar os arquivos e favorecer o entendimento da atividade, criamos um novo arquivo chamado eduroam dentro da pasta /etc/freeradius/ sites-enable/ e exclumos o inner-tunnel nela existente.
Vamos configurar o arquivo /etc/freeradius/sites-enable/eduroam. relevante citar que as informaes no constantes no arquivo mencionado sero pesquisadas no arquivo /etc/freeradius/sites-enable/default, que como o prprio nome sugere, contm as configura es padro do aplicativo.
server eduroam {
# Mtodos suportados para autorizao authorize { suffix auth_log files
# Manter comentado at a prxima prtica, onde habilitaremos o LDAP

eap {
ldap mschap pap
ok = return }
# mtodos suporados para autenticao. Onde buscar? Com que padro? authenticate {
# Manter comentado at a prxima prtica, onde habilitaremos o LDAP
75
# # #
Auth-Type LDAP{ ldap } Auth-Type PAP{ pap
Auth-Type MS-CHAP{ mschap
} eap
preacct { }
accounting { detail radutmp

unix attr_filter.accounting_response
session { radutmp
post-auth { } reply_log Post-Auth-Type REJECT { reply_log

76
pre-proxy { }
post-proxy { eap post_proxy_log attr_filter.post-proxy
Post-Proxy-Type Fail { detail } }
Configurando o ponto de acesso para autenticar em servidor RADIUS

Para finalizar as configuraes necessrias terceira prtica, precisamos configurar o servidor RADIUS para aceitar requisies de um ponto de acesso especfico e tambm confi gurar esse ponto de acesso para enviar pedidos de autenticao de usurios ao servidor RADIUS. Esse procedimento idntico ao j realizado na primeira atividade prtica, por isso sugerimos que o leitor consulte o final do Captulo 2. Com isso, encerra-se a etapa de configuraes propostas neste captulo. Atravs delas, possvel realizar autenticao e autorizao, por intermdio de um servidor RADIUS, onde cada usurio pode acessar a infraestrutura de rede sem fio utilizando seu login e senha cadastrados na base de usurios do servidor RADIUS.
77
78
5
LDAP Viso geral e conceitos fundamentais
objetivos
Conhecer os conceitos bsicos de um diretrio LDAP. Adquirir conhecimentos bsicos sobre a instalao e configurao de um servidor LDAP para operar no contexto do eduroam.
conceitos
Servio de diretrio. Estrutura e modelo de um diretrio LDAP. Classes de objetos, rvores e esquemas. O esquema brEduPerson.
Introduo
11 Um diretrio uma base de dados especializada. 22 Otimizada para busca e navegao. 22 Grande volume de informao textual. 33 Pessoas, instituies, servios etc. 22 Escrita e atualizao so espordicas, porm suportadas. 22 Pode ser local ou distribudo.
grupos, instituies e servios. Como base de dados, se distingue pelo grande volume de dados armazenados de forma a facilitar a busca e navegao, ou seja, trata-se de um sistema otimizado para leitura. As operaes de escrita e atualizao so menos comuns, porm so tambm suportadas. Um diretrio , portanto, diferente de um Sistema de Bancos de Dados (SGBD) Relacional, como o PostgreSQL. Um diretrio pode ser local, consistindo em informao concentrada em uma nica localidade (servidor) ou distribudo entre vrios servidores. Um exemplo recorrente de base de dados distribudo o sistema de nomes usado na Internet (Domain Name System DNS), onde uma hierarquia de servidores mantm partes de uma base de dados global (os nomes de domnios, como www.rnp.br ou mail.empresa.com.br). Entretanto, o DNS no navegvel (browsable) e no suporta buscas e, por isso, apesar de ser uma base de dados distribuda, no consiste propriamente de um diretrio. Um exemplo de diretrio o Open Directory Project (http://www.dmoz.org/), uma base de dados de links para pginas na web, organizadas em uma hierarquia, pesquisvel e navegvel.
Captulo 5 - LDAP Viso geral e conceitos fundamentais
Um diretrio uma base de dados que contm dados descritivos sobre entidades, pessoas,
79
Surgimento do LDAP
11 X.500. 22 Conjunto de padres do UIT para sistemas de diretrios. 22 Surgiu nos anos 1980. 11 DAP Directory Access Protocol. 22 Ou X.500 Directory Access Protocol. Era o protocolo de acesso a um diretrio X.500. 22 Baseado na pilha OSI. 11 Lightweight Directory Access Protocol LDAP. 22 Alternativa ao DAP. 22 Simplificado e baseado na pilha TCP/IP. 22 Atualmente na verso 3.
As empresas de telecomunicaes estiveram entre as primeiras a identificar a necessidade de um sistema de diretrios eficiente e escalvel, para armazenar listas telefnicas que permitissem localizao rpida. Com o avano da digitalizao dos sistemas de telefonia, nos anos 80, a Unio Internacional de Telecomunicaes (UIT) especificou o padro X.500, consistindo em um sistema de diretrios X.500 e seu respectivo protocolo de acesso, o X.500 Directory Access Protocol ou DAP. Esse protocolo foi concebido para operao sobre uma rede baseada no modelo Open Systems Interconnection (OSI). O LDAP, ou Lightweight DAP, surgiu como uma alternativa mais leve e foi implementado sobre a tecnologia TCP/IP, que comeava gradualmente a substituir as redes OSI ao longo dos anos 80 e 90. O LDAP um padro do IETF especificado na RFC 4510.
Verses do LDAP
11 LDAPv3. 22 Final dos anos 90.
22 Autenticao forte com SASL. 33 Suporte a certificados TLS e SSL. 22 Internacionalizao Unicode. 22 Encaminhamentos (Referrals). 11 LDAPv2 considerado ultrapassado. 22 Ainda suportado (OpenLDAP, desabilitado por default). 22 Incompatvel com o LDAPv3. A verso 3 do LDAP foi desenvolvida no final dos anos 90 em substituio verso 2 e oferecia as seguintes novas funcionalidades, entre outras: Autenticao forte com SASL O LDAPv2 suportava trs mtodos de autenticao: annimo (ou seja, sem autenticao), login e senha (em texto plano) e Kerberos (um mecanismo de autenticao cliente/servidor). O LDAPv3 introduziu o Simple Authentication and Security Layer (SASL) que, alm de suportar os mecanismos anteriores, passou a permitir outros mtodos de autenticao (como o TLS, por exemplo), de forma modular.
80
Internacionalizao: o LDAPv3 passou a dar suporte ao conjunto de caracteres Unicode, a evoluo do padro ISO 10646. Encaminhamentos: um encaminhamento (referral) uma informao enviada pelo servidor de volta ao cliente, indicando que a informao solicitada pode ser obtida de outra fonte. No LDAPv2, os encaminhamentos no eram suportados nativamente, sendo incorporados de forma improvisada e no padronizada em mensagens de erro (a mensagem de resposta parcial). Na verso 3, os encaminhamentos passaram a ser suportados nativamente. Atualmente o LDAPv2 considerado ultrapassado e, apesar de ainda suportado (por exemplo, pelo OpenLDAP), vem desabilitado por default. Alm disso, LDAPv2 e o LDAPv3 so incompatveis e sua implementao concorrente considerada difcil e problemtica.
Operao do LDAP
11 O LDAP segue o modelo cliente-servidor. 22 Cliente se conecta a um servidor e envia sua requisio. 22 Servidor responde e/ou envia ponteiro para outro servidor. 11 Consistncia na viso do cliente. 22 Mesmo resultado independente do servidor consultado. O LDAP um protocolo de aplicao que utiliza o modelo cliente-servidor. Um ou mais
servidores contm os dados que perfazem a rvore de informaes do diretrio (Directory Information Tree DIT). O cliente se conecta ao servidor, envia sua requisio e pode enviar vrias requisies ainda que no tenha obtido respostas. O servidor responde diretamente ou envia um ponteiro para outro servidor LDAP (encaminhamento/referral). Independente do servidor LDAP consultado, o cliente tem sempre a mesma viso de um diretrio.
Cliente e Servidor LDAP

Cliente LDAP: 11 Disponvel para os principais sistemas operacionais. Servidor LDAP: 11 Muitas vezes chamado Directory System Agent (DSA).
11 Opera, por padro, na porta 389. Existem clientes LDAP disponveis para os principais sistemas operacionais utilizados atualmente. Alguns exemplos so o Active Directory Explorer, para Windows; o Evolution, para Linux, e o Address Book, nativo do MacOS X. Existem tambm clientes multiplataforma, que funcionam baseados na web, como o FusionDirectory, o phpLDAPadmin e o JXplorer, entre outros. H tambm uma grande variedade de implementaes de servidores LDAP (tambm chamado de Directory System Agent DSA), tanto de grandes fabricantes (IBM Tivoli Directory Server, Oracle Internet Directory, Apple Open Directory, entre outros), como distribudos como software livre, como o OpenLDAP, sobre o qual nossos exemplos sero construdos.
11 Utiliza TCP como protocolo de transporte.
81
Protocolo LDAP
Transportado sobre TCP (porta padro 389). As opes de requisies do cliente LDAP so: 11 StartTLS: iniciar uma sesso TLS para criptografar a conexo. 11 Bind: autenticar e especificar a verso do protocolo LDAP a ser usada. 11 Search: realizar uma busca no diretrio. 11 Add/Delete/Modify/Move/Modify DN: adicionar, remover, modificar, mover ou renomear uma entrada. 11 Compare: testar se uma entrada possui determinado valor em um determinado atributo. 11 Abandon: desistir de uma requisio. 11 Unbind: encerrar a conexo. O cliente se comunica com os servidores atravs de requisies enviadas com o protocolo
LDAP. O protocolo LDAP utiliza o transporte confivel oferecido pelo TCP e o servidor LDAP escuta, por padro, a porta 389. A principal requisio a de busca, search, mas existem tambm as requisies que permitem editar o contedo da base (como Add, Delete e Modify). As requisies Bind e Unbind so usadas para iniciar e encerrar conexes LDAP. O cliente pode enviar vrias requisies, mesmo sem ter recebido respostas, e o servidor pode respond-las em qualquer ordem.
Figura 5.1 Exemplo da visualizao de uma rvore de diretrios LDAP (a) e (b).
Organizao e estruturas do LDAP
c = GB
c = US
dc = net st = California
dc = com
dc=DE
The Organisation o = Acme ou = Marketing
The Organisation dc = example
ou = Servers
Organisation Unit ou = Sales
Organisation Unit ou = People
Person cn = Barbara Jenson
Person uid = babs
82
A unidade bsica de informao no LDAP a entrada (entry). As entradas so arranjadas de forma hierrquica atravs de uma estrutura em rvore, chamada Directory Information Tree (DIT). Conforme podemos ver na Figura 5.1a, as entradas referentes aos pases aparecem no topo da hierarquia, seguidas pelos estados e organizaes, por sua vez povoadas por unidades, pessoas, dispositivos, documentos etc. Outra forma de organizao da rvore LDAP, e que tem sido popularizada, baseada nos nomes de domnios da internet e est representada na Figura 5.1b. Essa abordagem ajuda a localizao de diretrios atravs do servio de DNS.
Modelos LDAP
So quatro os modelos bsicos definidos pelo LDAP (em conjunto, eles descrevem completamente a operao do diretrio): 11 Modelo de Informao: define o tipo de informao que pode ser armazenada. 11 Modelo de Nomes: define como a informao pode ser organizada e referenciada. 11 Modelo Funcional: descreve as operaes que podem ser realizadas nos dados. 11 Modelo de Segurana: recomenda os mecanismos de autenticao e controle de acesso a serem usados. Considerando os objetivos deste livro, abordaremos mais detalhadamente apenas o Modelo de Informao.
Modelo de Informao do LDAP

11 Entradas so os contineres de dados da estrutura hierrquica. 11 Directory Information Tree (DIT) a rvore resultante. 11 O topo da hierarquia chamado raiz, base ou sufixo. 11 Cada entrada possui um nome nico e uma instncia de um ou mais objectClasses. 11 Cada objectClass tem um nome e pode conter atributos. 11 Cada atributo tem um nome e usualmente contm dados. 11 Os dados so, portanto, armazenados como atributos.
Como dissemos, em um diretrio LDAP os dados so representados em uma estrutura hierrInformation Tree (DIT). O topo da hierarquia chamado de raiz (root), base ou sufixo. Cada entrada na rvore contm uma entrada pai e zero ou mais entradas filho (objetos). Cada entrada uma instncia de uma ou mais classes de objetos (objectClasses) e possui um nome nico. As objectClasses contm zero ou mais atributos e definem os atributos obrigat rios e opcionais. Os atributos possuem nomes e podem tambm possuir apelidos (aliases) e abreviaes. Os dados de interesse do LDAP esto armazenados sob a forma de atributos.
quica de objetos, chamados entradas (entries). A rvore resultante chamada de Directory
Tipos de classe de objeto

11 objectClasses podem ser de trs tipos: 22 Abstratas: modelo para criao de outras classes. 22 Estruturais: classes instanciadas pelas entradas. 22 Auxiliares: tambm instanciadas pelas entradas, mas apenas para estender as classes estruturais.
83
11 A definio de que classes so abstratas, estruturais ou auxiliares definida por um esquema (estudado adiante). Uma classe de objetos pode ser declarada como classe abstrata, estrutural ou auxiliar. Classes de objetos abstratas so usadas como modelo para criao de outras classes e as
entradas do diretrio no podem ser instncias de classes de objeto abstratas. Entradas do diretrio so sempre instncias de classes de objetos estruturais. Uma classe auxiliar serve para estender uma classe estrutural e no pode ser a nica a instanciar uma entrada do diretrio. Uma entrada de diretrio deve instanciar ao menos uma classe estrutural.
Directory Information Tree

DIT
root objectClass = name entry objectClass-name-value attribute-name-value attribute-name-value ... attribute-name-value [dened using ASN.1] objectClass = name entry Irmo entry Irmo objectClass-name-value attribute-name-value attribute-name-value ... attribute-name-value [dened using ASN.1] A Figura 5.2 ilustra uma Directory Information Tree (DIT) bastante simplificada. Nota-se que uma determinada entrada (entry) instncia de diversas objectClasses que possuem, cada
Filho
Pai
Figura 5.2 Exemplo de DIT e seus objectClasses.
uma, diversos atributos. Uma entrada pode possuir parents, childs e siblings (entradas de nvel superior, inferior ou mesmo nvel na hierarquia).
Descrio da rvore e das entradas LDIF

11 LDIF = LDAP Data Interchange Format. 11 Descrio textual da rvore hierrquica.
dn: uid=jsliva, dc=uff, dc=br sn: Silva cn: Jose uid: jsilva objectClass: person objectClass: inetOrgPerson objectClass: sambaSamAccount
84
userPassword: {SSHA}gWRX6IuyiGw+0xvPN3JhaGEcvuLJqmlB sambaNTPassword: 1E39A9A92F2B08A0E69B4D5ADA7E5332

LDIF (Data Interchange Format LDAP) descreve textualmente trechos da rvore hierrquica (DIT) e contm valores de cada atributo de cada entrada. Note que um servidor contm uma subrvore da rvore global do LDAP (por exemplo, todas as entradas sob o domnio uff.br) e que, nesse caso, essa subrvore estar definida em um arquivo LDIF. O exemplo mostra um trecho de um arquivo LDIF, referente entrada do usurio jsilva associado instituio uff.br ( Jos Silva, no caso): 11 dn o nome nico (distinguished name) da entrada. 11 dcs so componentes do nome de domnio (domain component). Nesse caso, do domnio .uff.br. O objeto no exemplo instncia de trs objectClasses: person, inetOrgPerson e sambaSamAccount. Essas classes (em conjunto) definem uma coleo de atributos para a entrada: 11 cn e sn designam, respectivamente o nome e sobrenome. 11 uid o user id do usurio. 11 sambaNTPassword a senha do usurio em formato suportado pelo MSCHAPv2. 11 userPassword a senha do usurio em formato suportado pelo PAP.
Esquemas LDAP
11 Um esquema LDAP consiste em um pacote contendo objectClasses e atributos. 11 Forma prtica de encapsular atributos e classes que traduzem o interesse especfico de uma instituio. 11 Todos os atributos e objectClasses, incluindo os atributos e objectClasses superiores na hierarquia. 11 Esquemas so configurados no servidor LDAP. Um esquema LDAP define as regras e a sintaxe, assim como a lista de objectClasses, seus tipos e atributos de uma subrvore. O esquema facilita o empacotamento dos atributos e usar diferentes esquemas. Todos os atributos e objectClasses, incluindo os atributos e objectClasses superiores na hierarquia, devem ser definidos pelos esquemas em uso. Um esquema de particular interesse no contexto do eduroam o brEduPerson, indicado pela federao Comunidade Acadmica Federada (CAFe), comentado a seguir. classes de interesse especfico de uma instituio, ou seja, diferentes instituies podem
Esquema brEduPerson
11 Objetiva armazenar dados de pessoas ligadas s instituies de ensino superior no Brasil. 22 Professores, funcionrios, alunos e pesquisadores. 22 Suporta mltiplos vnculos com a instituio. 11 Informaes de residentes no Brasil e informaes especificamente ligadas comunidade acadmica.
85
O esquema brEduPerson foi criado para permitir o armazenamento dos dados de pessoas ligadas s instituies de ensino superior no Brasil e seus (possivelmente mltiplos) vnculos. Esse esquema armazena informaes especficas para a realidade brasileira, tais como informaes genricas sobre residentes no pas (como o CPF) e dados especficos sobre os membros de uma instituio (email, cargo, matrcula, data de ingresso etc.). O brEduPerson pode ser utilizado de forma integrada com outros esquemas LDAP que tambm descrevem informaes sobre pessoas, como o eduPerson, mantido pelo grupo Mace da Internet2, ou o Schema for Academia (Schac), mantido pela Trans-European Research and Education Networking Association (Terena).
Classes de objetos no esquema brEduPerson

11 Entrada principal: 22 inetOrgPerson (estrutural). 22 schacPersonalCharacteristics, eduPerson e brPerson (auxiliares). 11 inetOrgPerson pessoas (RFC 2798). 11 schacPersonalCharacteristics extenses ao inetOrgPerson. 22 Sugeridas pela Terena. 11 eduPerson pessoas ligadas comunidade acadmica. 22 Criado no mbito da Internet2. 11 brPerson dados de um brasileiro ou residente no pas. 22 CPF e passaporte. No brEduPerson, a entrada principal de cada usurio um objeto estrutural da classe
inetOrgPerson (definida pela RFC 2798), com classes auxiliares schacPersonalCharacteristics (parte do esquema Schac), eduPerson (parte do esquema eduPerson) e brPerson. A classe brPerson tem o objetivo de capturar atributos especficos de pessoas que vivem no Brasil, como CPF e nmero do passaporte.
Para saber mais sobre os esquemas eduPerson, Schac e brEduPerson, consulte os sites da Internet 2, da Terena e da RNP: http://middleware.internet2.edu/eduperson/ http://www.terena.org/activities/tf-emc2/docs/schac/schac-schema-IAD-1.4.1.pdf http://wiki.rnp.br/download/attachments/41190038/BrEduPersonv1_0.pdf?version=1&modif icationDate=12797396430002
OpenLDAP
Implementao de cdigo aberto do LDAP para o sistema operacional Linux, que inclui: 11 Slapd o servidor (stand-alone LDAP daemon). 11 Bibliotecas que implementam o protocolo LDAP. 11 Utilitrios, ferramentas e amostras de configuraes e clientes. 11 Exemplos: ldapadd e ldapsearch. O OpenLDAP (http://www.openldap.org) uma implementao de cdigo aberto do LDAP para o sistema operacional Linux. Alm do servidor (slapd = Standalone LDAP Daemon), a distribuio inclui as bibliotecas que implementam o protocolo LDAP e uma srie de
86
utilitrios, como ldapadd, que permite adicionar entradas base de dados no formato LDIF, e ldasearch, que permite a realizao de buscas no diretrio.
OpenLDAP: iniciando e parando o servidor

11 Iniciando...
/usr/local/libexec/slapd [<option>]*
11 Exemplos de opes:
-f arquivo (arquivo de configurao alternativo) -d nvel (nvel de debug)

11 Parando... kill -INT `cat /usr/local/var/slapd.pid
A localizao do slapd e do pid file determinada na instalao e pode variar.
Para iniciar o servidor, basta evocar diretamente o executvel slapd, cuja localizao default /usr/local/libexec (configurvel durante a instalao). O daemon aceita opes como f, para informar um arquivo de configurao alternativo (a localizao default do arquivo de configurao /usr/local/etc/openldap/slapd.conf ), ou -d
Saiba mais
Para mais detalhes sobre essas opes acesse o site do OpenLDAP: http://www.openldap. org/doc/admin24/ runningslapd. html#Command-Line%20Options
para configurar o nvel de debug. Assim, para iniciar o servidor, basta digitar:
/usr/local/libexec/slapd
Para interromper o servidor, basta enviar ao daemon slapd o sinal INT (interrupt). O identificador do processo (PID) pode ser lido do arquivo de pid, cuja localizao default (tambm configurvel na instalao) /usr/local/var/slapd.pid. Portanto, para interromper o servidor, basta digitar:
kill -INT `cat /usr/local/var/slapd.pid
Atividade Prtica 4 e Instalao e configurao de um servidor LDAP

Resumo dos dados utilizados nesta atividade prtica Domnio utilizado rnpteste.br O que corresponde DIT: dc=rnpteste,dc=br Usurio de teste criado Senha do usurio de teste Senha compartilhada entre Localhost e FreeRADIUS Usurio de administrao do LDAP Senha do usurio de administrao do LDAP teste senha1 eduroam123 admin Criada por voc no momento do dkpg-reconfigure
87
Arquivos editados Arquivo pivot de suporte MSCHAPv2 Arquivo de importao do suporte MSCHAPv2 Arquivo de modulo do LDAP no FreeRADIUS Arquivo de habilitao do mdulo LDAP no FreeRADIUS /tmp/schema_convert.conf /tmp/ldif_output/cn\=config/cn\=schema/cn\=\{13\}samba.ldif /etc/freeradius/modules/ldap /etc/freeradius/sites-enable/inner-tunnel (padro) Ou se voc seguiu o tutorial e criou um arquivo novo chamado eduroam /etc/freeradius/sites-enable/eduroam Arquivo de insero do usurio no LDAP user.ldif
Ponto de Acesso
Usurio
Servidor LDAP Instituio 1
Figura 5.3 Prtica de configurao do servidor LDAP.
A quarta atividade prtica tem como objetivo realizar a instalao e configurao de um servidor LDAP representando a base de usurios de uma instituio de ensino e pesquisa. Ser feita tambm a configurao do servio RADIUS para consulta das credenciais de um usurio na base LDAP. Primeiro vamos instalar o OpenLDAP no servidor:
# apt-get install slapd ldap-utils

Voc ser questionado sobre a senha do administrador do OpenLDAP. Ao final deste processo, voc ver as linhas de inicializao do OpenLDAP:
Creating new user openldap... done. Creating initial configuration... done. Creating LDAP directory... done. Starting OpenLDAP: slapd.
Configuraes bsicas
A configurao padro, apenas para constar, caso no utilizssemos a interface de configu rao mais frente, seria:
# cat /usr/share/doc/slapd/examples/slapd.conf include include /etc/ldap/schema/core.schema /etc/ldap/schema/cosine.schema
88
include include pidfile argsfile loglevel modulepath moduleload sizelimit 500 tool-threads 1 backend database suffix directory
/etc/ldap/schema/nis.schema /etc/ldap/schema/inetorgperson.schema /var/run/slapd/slapd.pid /var/run/slapd/slapd.args none /usr/lib/ldap back_@BACKEND@
@BACKEND@ @BACKEND@ @SUFFIX@ /var/lib/ldap
dbconfig set_cachesize 0 2097152 0 dbconfig set_lk_max_objects 1500 dbconfig set_lk_max_locks 1500 dbconfig set_lk_max_lockers 1500 index lastmod checkpoint objectClass eq on 512 30
access to attrs=userPassword,shadowLastChange by dn=@ADMIN@ write

by anonymous auth by self write by * none access to dn.base= by * read access to * by dn=@ADMIN@ write by * read
Por padro, o OpenLDAP executa com uma base mnima. Como no queremos que a base OpenLDAP criada esteja diretamente vinculada ao domnio configurado na instalao do nosso servidor, executamos o comando de reconfigurao da base:
# dpkg-reconfigure slapd
89
E voc poder editar todos os principais detalhes do seu servidor OpenLDAP. Uma observao, no nosso exemplo o domnio utilizado, foi: rnpteste.br, ento a base esperada deve ficar: dc=rnpteste,dc=br. Novamente, apenas para constar, se a base fosse criada manualmente, poderia utilizar um arquivo LDIF da seguinte forma:
# vim base.ldif dn: dc=admin,dc=rnpteste,dc=br objectClass: top objectClass: dcObject objectClass: organization o: rnpteste.br dc: rnpteste structuralObjectClass: organization
dn: cn=admin,dc=rnptest,dc=br objectClass: simpleSecurityObject objectClass: organizationalRole cn: admin description: LDAP administrator userPassword:: e1NTSEF9SHVBVHJ5K3Bwc0diemVqVERXUzU5YVcvWVB4a1hveUo= structuralObjectClass: organizationalRole
Essa a base mnima para o domniornpteste.br, com isso, podemos inicializar o uso bsico do OpenLDAP.
Adicionando oschemado Samba no OpenLDAP

Se voc precisar utilizar usurios comhashesNT/LM, ser necessrio inserir oschemado Samba. Esse esquema necessrio para oferecer o mtodo de autenticao MSCHAPv2.
# apt-get install samba-doc

O arquivosamba.schema.gz, que queremos, vai estar em/usr/share/doc/samba-doc/examples/LDAP/. Agora precisamos convert-lo para o novo padro do OpenLDAP. Primeiro vamos copiar este esquema para dentro do OpenLDAP:
# zcat /usr/share/doc/samba-doc/examples/LDAP/samba.schema.gz > / etc/ldap/schema/samba.schema

Criar um arquivo que ser utilizado como piv para a converso:
# vim /tmp/schema_convert.conf include /etc/ldap/schema/core.schema include /etc/ldap/schema/collective.schema
90
include /etc/ldap/schema/corba.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/duaconf.schema include /etc/ldap/schema/dyngroup.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/java.schema include /etc/ldap/schema/misc.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/openldap.schema include /etc/ldap/schema/pmi.schema include /etc/ldap/schema/ppolicy.schema include /etc/ldap/schema/samba.schema
Criar um diretrio de sada para a configurao:
# mkdir /tmp/ldif_output
E agora vamos usar o comandoslaptestpara converter osschemas:
# cd /tmp # slaptest -f schema_convert.conf -F /tmp/ldif_output/ config file testing succeeded

Ele vai gerar vrios arquivos.ldifdentro de/tmp/ldif_output/cn=config/cn=schema. O que nos interessa o do Samba, por isso, vamos editar apenas ele (cn={13}samba.ldif ) e retirar as informaes desnecessrias. Ao abrir o arquivo, voc vai ver algo como:
dn: cn={13}samba objectClass: olcSchemaConfig

cn: {13}samba ...

Altere para:
dn: cn=samba,cn=schema,cn=config objectClass: olcSchemaConfig cn: samba ...

E no final do arquivo, voc deve remover as entradas:
structuralObjectClass: olcSchemaConfig entryUUID: 3a14cf38-c77b-102f-97af-e37d8ac36f95
91
creatorsName: cn=config createTimestamp: 20110208025944Z entryCSN: 20110208025944.971133Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20110208025944Z
Feito isso, nosso schema do Samba foi alterado para o padro atual. Vamos adicionar o novo schema no OpenLDAP. Reinicialize o OpenLDAP:
# /etc/init.d/slapd restart
Agora vamos adicionar o schema do Samba na base do OpenLDAP, lembrando que a senha abaixo a senha que adicionamos na configurao do OpenLDAP:
# ldapadd -Y EXTERNAL -H ldapi:/// -f /tmp/ldif_output/cn\=config/ cn\=schema/cn\=\{13\}samba.ldif

O resultado ser a seguinte linha:
adding new entry cn=samba,cn=schema,cn=config

Feito isso, o schema do Samba foi adicionado corretamente.
Autenticando no OpenLDAP
Depois de instalar oOpenLDAPem um servidor, devemos configurar o FreeRADIUS para autenticar noOpenLDAP. necessrio adicionar o suporte ao LDAP pelo FreeRADIUS, e isso simples com o seguinte comando:
apt-get install freeradius-ldap

Vamos editar o mdulo doOpenLDAP da forma indicada a seguir:
# vim /etc/freeradius/modules/ldap ldap { server = localhost basedn = dc=rnpteste,dc=br # # identity = cn=admin,dc=rnpteste,dc=br password = senha_do_leitor_da_base_ldap
filter = (uid=%{%{Stripped-User-Name}:-%{User-Name}}) ldap_connections_number = 5 timeout = 4 timelimit = 3 net_timeout = 1
92
tls { start_tls = no } dictionary_mapping = ${confdir}/ldap.attrmap edir_account_policy_check = no set_auth_type = no }

Feito isso, a comunicao do FreeRADIUS com oOpenLDAPest configurada. O prximo passo ativar oLDAPcomo mtodo de autenticao nossites, editando o arquivo default :
# vim /etc/freeradius/sites-enabled/default authorize { ... ldap ... }
authenticate { ... Auth-Type LDAP { ldap } ... }

A priori, o que interessa que, emauthorize, voc tire o comentrio da linha que contm oLDAPe, emauthenticate, a parte que fala sobre o tipo de autenticao LDAP. Faa o mesmo no arquivoeduroam:
# vim /etc/freeradius/sites-enabled/eduroam authorize { ... ldap ... }
authenticate {
93
... Auth-Type LDAP { ldap } ... }

Deixe as outras configuraes como esto (no precisa alter-las). Vamos agora testar para verificar se o funcionamento conforme o esperado.
Criando um usurio para testes

Vamos adicionar um usurio que ser utilizado nos testes com o FreeRADIUS autenticando no OpenLDAP:
# vim user.ldif dn: uid=teste,dc=rnpteste,dc=br sn: do Teste cn: Teste do Teste uid: teste objectClass: person objectClass: inetOrgPerson objectClass: sambaSamAccount userPassword: {SSHA}gWRX6IuyiGw+0xvPN3JhaGEcvuLJqmlB sambaNTPassword: 1E39A9A92F2B08A0E69B4D5ADA7E5332
sambaSID: 1
A senha desse usurio senha1. Vamos adicion-lo na base do OpenLDAP:
# ldapadd -x W -D cn=admin,dc=rnpteste,dc=br -f user.ldif

Se o usurio foi adicionado com sucesso, a seguinte mensagem vai aparecer:
adding new entry uid=teste,dc=rnpteste,dc=br

Feito isso, podemos usar o radtest para testar a autenticao com as credenciais desse usurio.
# radtest -t mschap teste senha1 localhost:1812 0 eduroam123

Ondeteste o nosso usurio da base OpenLDAP, se a reposta for parecida com:
Sending Access-Request of id 151 to 127.0.0.1 port 1812 User-Name = teste NAS-IP-Address = 200.129.192.94 NAS-Port = 1812
94
MS-CHAP-Challenge = 0x2ff26066cb1a2416 MS-CHAP-Response = 0x0001000000000000000000000000000000000000000 0000000006f252f352fd4c0af86d8c3737866243af03519ca1458866f rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=151, length=84 MS-CHAP-MPPE-Keys = 0x00000000000000005610a3a37fcccde5c7d37764aa0b97930000000000000000 MS-MPPE-Encryption-Policy = 0x00000001 MS-MPPE-Encryption-Types = 0x00000006
O usurio foi autenticado corretamente.
95
96
6
Roaming no eduroam: conceitos e funcionamento
objetivos
Compreender o conceito de roaming e a importncia de um sistema hierrquico de autenticao para viabilizar a mobilidade de usurios entre instituies. Adquirir conhecimentos bsicos sobre a configurao de servidores de autenticao federados.
conceitos
Federao hierrquica para autenticao com RADIUS. Domnios (realms) e servidores de encaminhamento (proxy RADIUS).
Introduo
11 Finalidade do roaming: 22 Prover acesso transparente a usurios em instituies parceiras independentes. 22 Manter identidade nica. 22 Mtodos de autenticao so selecionados na instituio de origem. 22 Integrar o servio RADIUS geograficamente.
O roaming desempenha a principal funo do servio eduroam (education roaming), que integrar e tornar transparente ao usurio da comunidade acadmica o acesso rede em uma instituio parceira visitada. O roaming facilita o acesso do usurio pelo fato de permitir que seja utilizada apenas uma nica identidade, aquela criada em sua instituio de origem. Todas essas funcionalidades se devem tambm ao fato de que o mtodo de autenticao do usurio no ser alterado em momento algum durante o encaminhamento dos pacotes RADIUS, preservando, assim, os mtodos EAP selecionados por sua instituio de origem (PAP, MSCHAPv2 etc.).
Captulo 6 - Roaming no eduroam: conceitos e funcionamento
11 Premissa bsica do eduroam.
97
Estrutura hierrquica
3 Nvel Confederao
2 Nvel Federao
.br
.ar
Figura 6.1 Exemplo de hierarquia de servidores eduroam em nvel continental.
1 Nvel Institucional UFRJ UFMS UFF
Como j foi estudado, o eduroam utiliza estrutura hierrquica de trs nveis de servidores de autenticao, onde o primeiro nvel compreende as instituies participantes. No segundo nvel, h o ponto central do pas (representando a federao), ao qual a instituio subordinada. Finalmente, no terceiro nvel dessa hierarquia, est o servidor da confederao, que aquele que interliga todos os servidores das federaes participantes. A estrutura hierrquica de servidores configurada estaticamente pelos administradores do servio, atravs da edio de arquivos de configurao dos servidores RADIUS.
Realms (domnio)
11 Identificao da instituio de origem. 11 Definido por um delimitador @. 22 Outro delimitador seria o \ (exemplo: domnio Windows).
Para que o acesso seja transparente ao usurio em roaming, configure sempre login@dominio. Os realms (domnios) identificam qual a instituio de origem do usurio. a partir dessa informao que o servidor RADIUS saber como encontrar a instituio originria do usurio. Pode-se fazer um paralelo, nesse momento, com a hierarquia DNS. Por conta da forma como o RADIUS funciona, recomendvel que sempre ao configurar o dispositivo o usurio utilize seu login informando o domnio correspondente sua instituio. Isso porque, caso no seja indicado nenhum domnio, o servidor RADIUS da instituio visitada tentar autenticar aquele usurio localmente, isto , como se o usurio fosse da prpria instituio. Nesse caso, o acesso do usurio em uma instituio visitada no ser transparente, pois sua requisio de acesso no ser enviada sua instituio de origem. Para conseguir o acesso rede na instituio visitada, seria necessrio reconfigurar suas credenciais, informando o domnio que representa sua instituio de origem.
98
Infraestrutura do provedor de acesso

2 Nvel Federao instituto.br
Federao Proxy RADIUS
universidade.br
1 Nvel Institucional
Instituio A: Servidor RADIUS
Instituio B: Servidor RADIUS
Ponto de Acesso
Figura 6.2 Exemplo de infraestrutura eduroam com duas instituies distintas.
Servidor LDAP
Servidor LDAP
Processo de autenticao local

2 Nvel Federao usuario@instituto.br senha universidade.br
Instituio A: Servidor RADIUS Instituio B: Servidor RADIUS Federao Proxy RADIUS
Ponto de Acesso
Figura 6.3 Exemplo de um processo de autenticao de um usurio local.
Servidor LDAP
Servidor LDAP
A Figura 6.2 ilustra um exemplo de infraestrutura de servidores RADIUS e LDAP, representando duas instituies distintas que oferecem o servio eduroam. Para permitir a mobilidade de usurios entre essas instituies, necessria a comunicao entre os servidores RADIUS de cada instituio e o servidor RADIUS da federao. A Figura 6.3 ilustra o mesmo cenrio, considerando um pedido de acesso local de um usurio da Universidade Federal Fluminense (UFF) (exemplo: usuario@uff.br). Nesse caso, o pedido de autenticao para acesso desse usurio ser tratado localmente pelo servidor RADIUS de sua instituio (UFF, no exemplo).
99
Processo de Autenticao Remota

usuario@universidade.br senha
2 Nvel Federao usuario@instituto.br senha
Federao Proxy RADIUS
universidade.br
Instituio A: Servidor RADIUS Instituio B: Servidor RADIUS
Ponto de Acesso
Servidor LDAP
Servidor LDAP
Figura 6.4 Exemplo de autenticao de usurio em roaming.
A Figura 6.4 apresenta outro exemplo que ilustra a mobilidade de usurios entre instituies, onde a funcionalidade de roaming utilizada. No exemplo, um usurio da Universidade Federal do Rio de Janeiro (UFRJ) (exemplo: usuario@ufrj.br) visita a Universidade Federal Fluminense (UFF). O pedido de autenticao desse usurio ser recebido pelo servidor RADIUS da instituio visitada (UFF), que por sua vez, ao verificar que o domnio relacionado ao usurio no corresponde ao domnio local, encaminhar a solicitao ao servidor de nvel acima (federao). Uma vez encontrada a instituio de origem do usurio (UFRJ, no exemplo), a requisio ento encaminhada ao seu servidor RADIUS, que realiza a verificao necessria e retorna a resposta pelo caminho contrrio.
Servidor de encaminhamento proxy RADIUS

O servidor proxy encaminha de forma transparente os pacotes de: 11 Access-Request. 11 Access-Response. 11 Access-Reject. 11 Access-Accept. Atributo Proxy-State: 11 Inserido e removido (no retorno da mensagem) pelo servidor de encaminhamento. 11 Identifica que a mensagem veio de um proxy. 11 No removido no caminho de ida, mas podem ser acrescentados mais atributos Proxy-State. O papel do servidor RADIUS de uma instituio visitada (servidor de encaminhamento ou
proxy) intermediar a transao que se dar entre o autenticador local (o ponto de acesso na instituio visitada) e o servidor RADIUS da instituio de origem. Para isso, ele dever encaminhar as mensagens de Access-Request, Access-Response, Access-Reject e Access-Accept trocadas por esses dois agentes. Como vimos, a instituio de origem do usurio identificada pelo seu domnio. Quando um servidor RADIUS recebe uma solicitao de
100
l
Saiba mais
possvel utilizar uma identificao externa (outer tunnel fora do tnel) diferente da original (por exemplo, anonymous@dominio_ real), mantendo a identificao correta (usuario_real@dominio_ real), a ser realmente consultada no servidor de origem do usurio, apenas dentro do tnel (inner-tunnel). Essa forma bem difundida na comunidade eduroam e visa ocultar a identificao real do usurio em roaming, uma vez que o servidor de encaminhamento necessita apenas do domnio para realizar o encaminhamento da mensagem.
autenticao para um usurio que no local, ele insere o atributo Proxy-State nesta requisio e a encaminha ao servidor RADIUS de prximo nvel, seguindo a hierarquia de servidores pr-configurada. Todos os servidores intermedirios, ao encaminharem mensa gens RADIUS, inserem o atributo Proxy-State na mensagem e devem remov-lo assim que a mensagem de resposta retornar, entregando ao autenticador a mensagem final, sem esse atributo. por isso que dizemos que o processo se d de forma transparente, tanto para o autenticador quanto para o prprio suplicante.
Atividade Prtica 5 e Configurao de proxy para a federao (roaming)

Resumo dos dados utilizados nesta atividade prtica Usurio de teste Senha do usurio de teste Senha compartilhada entre o servidor RADIUS da instituio (aluno) e o RADIUS da federao (professor) Arquivos editados Configurao do proxy, responsvel por todo redirecionamento da instituio para a federao Liberao da comunicao com o servidor da federao /etc/freeradius/proxy.conf /etc/freeradius/clients.conf Qualquer um criado anteriormente, tanto o do arquivo de texto quando o do LDAP As respectivas Usualmente: eduroam123
UDP Ponto de Acesso Servidor RADIUS Instituio 1
Servidor RADIUS Federao
UDP
Servidor RADIUS Instituio 2 Servidor LDAP Instituio 1

Usurio
Figura 6.5 Destaque do servidor a ser configurado durante a atividade prtica.
A quinta atividade prtica tem como objetivo configurar um servidor RADIUS representando uma instituio de ensino e pesquisa para que esta oferea o servio de roaming. Essa prtica mostrar tambm as configuraes necessrias no servidor da federao eduroam, representando um determinado pas, para que uma nova instituio faa parte dessa federao e oferea o servio de roaming. A configurao do proxy do servidor RADIUS da instituio se faz necessria para o encami nhamento de requisies de autenticao por usurios no pertencentes ao domnio local. Sendo assim, ser avaliado pelo proxy RADIUS da instituio se o domnio do usurio local ou se a requisio deve ser encaminhando ao servidor da federao eduroam, que por sua vez a encaminhar instituio de origem do usurio.
101
Ser necessria a configurao do arquivo proxy.conf localizado no diretrio /etc/freeradius/ contendo no mnimo a configurao a seguir:
proxy server { default_fallback } = no
home_server eduroam-br { type ipaddr port secret = auth+acct = IP_SERVIDOR_FEDERACAO = 1812 = CHAVE_COMPARTILHADA
require_message_authenticator = yes response_window zombie_period revive_interval status_check check_interval num_answers_to_alive = 20 = 40 = 120 = status-server = 30 = 3
coa {
irt = 2 mrt = 16 mrc = 5 mrd = 30 } }
home_server_pool EDUROAM-FTLR { # Garantir disponibilidade type = fail-over
102
home_server }
= eduroam-br
realm DEFAULT { auth_pool nostrip } realm LOCAL { } = EDUROAM-FTLR acct_pool = EDUROAM-FTLR
realm NULL { secret } = CHAVE_COMPARTILHADA
realm uff.br { }
Basicamente, a configurao compreender o seu domnio local, em nosso caso representado por realm uff.br, onde os parmetros de accthost e authhost correspondem, respectivamente, ao endereo do servidor de accounting e ao servidor de autenticao. Atente para o fato de que, caso a consulta seja local, fica subentendida a realizao do strip (por meio do parmetro suffix, que dever estar habilitado em seu arquivo de virtual_server Arquivo inner_tunnel), considere que recebemos teste@uff.br. Ser realizada a separao deste usurio teste de seu domnio uff.br para verificao de realm e de usurio na base de dados utilizada. A configurao do realm DEFAULT uma das mais importantes. nessa seo que sero criados o pool EDUROAM-FTLR, responsvel pelo encaminhamento ao servidor da federao. A opo nostrip necessria porque queremos que o login completo do usurio chegue ao servidor da federao, para que seja possvel realizar a comparao de realms e verificar para onde ser encaminhada sua requisio. Em EDUROAM-FTLR apontada a configurao para o servidor da federao, no caso, eduroam-br. Foi criado esse pool para que seja possvel cadastrar mais de um servidor da federao, para que oferecer redundncia (fail-over). O home_server eduroam-br expe as configuraes propriamente ditas para a comunicao do servidor da instituio com a federao. Substitua realm uff.br pelo domnio de sua insti tuio. Observao: importante ficar atento chave compartilhada e se o IP do servidor de sua instituio est cadastrado no clients.conf da federao, assim como o IP do servidor da federao no clients.conf de sua instituio. 103
que nada mais que a separao da identificao do usurio de seu domnio. Por exemplo,
Adicione o IP do servidor RADIUS da federao em seu clients.conf.
Configurando o proxy da federao

Esta configurao ser realizada apenas no servidor da federao, ou seja, somente o professor dever executar a configurao a seguir, a fim de criar a estrutura de federao internamente ao laboratrio. Contedo do arquivo clients.conf.
# localhost client localhost { ipaddr secret = 127.0.0.1 = SENHA_COMPARTILHADA
require_message_authenticator = no nastype } = other
# Instituicao XX client 200.20.0.XX/24 { secret shortname } = SENHA_COMPARTILHADA = eduroam-uff
# Instituio YY client 200.129.192.YY { secret shortname } = SENHA_COMPARTILHADA = UFMS
# CONFEDERACAO LATLR client 200.37.WW.UU { secret shortname } = SENHA_COMPARTILHADA_FEDERACAO = LATLR
104
Contedo do arquivo proxy.conf.
# LATLR home_server eduroam-la { type = auth+acct ipaddr = 200.37.WW.UU port = 1812 secret = SENHA_COMPARTILHADA_FEDERACAO require_message_authenticator = yes response_window = 20 zombie_period = 5 revive_interval = 20 status_check = status-server check_interval = 30 num_answers_to_alive = 3 coa { irt = 2 mrt = 16 mrc = 5 mrd = 30 } }
home_server_pool LATLR { type = fail-over home_server = eduroam-la }
realm DEFAULT {
105
auth_pool = LATLR acct_pool = LATLR nostrip }
realm LOCAL { }
realm NULL { secret = SENHA_COMPARTILHADA_FEDERACAO }
#INSTITUICOES # UFF realm uff.br { authhost accthost secret nostrip }

= 200.20.0.XX:1812 = 200.20.0.XX:1813 = SENHA_COMPARTILHADA
# UFRJ realm ufrj.br { authhost accthost secret nostrip } = 200.129.192.YY:1812 = 200.129.192.YY:1813 = SENHA_COMPARTILHADA
Teste de roaming
Realize testes de autenticao de seu usurio utilizando um ponto de acesso de outra instituio, ou utilize o radtest diretamente do seu servidor informando um usurio de outra instituio.
106
7
RadSec: Segurana na comunicao RADIUS
objetivos
Compreender a importncia do uso de criptografia na comunicao entre os componentes da arquitetura RADIUS. Adquirir conhecimentos bsicos sobre a instalao e configurao essencial do RadSec e entender suas limitaes.
conceitos
RadSec e radsecproxy. Criptografia e comunicao segura com TLS.
Introduo
11 RadSec (RADIUS-over-TLS): 22 Especificado (ainda como draft) na RFC 6614 Transport Layer Security (TLS) Encryption for RADIUS, de 2012. 22 Diversos drafts desde 2008. 22 Altera a comunicao RADIUS baseada em UDP para TCP/TLS. 11 Benefcios do RadSec: 22 Segurana (TLS). 22 Confiabilidade (TCP). O RADIUS, executado sobre TLS (RADIUS over TLS), mais conhecido como RadSec, est documentado na RFC 6614, de 2012 , e ainda um draft (rascunho), ou seja, uma proposta
de padro. A sua principal premissa alterar a comunicao baseada no protocolo UDP, utilizada tradicionalmente pelos servidores RADIUS, para uma comunicao baseada em TCP e protegida pelo protocolo criptogrfico TLS. Seus principais benefcios em relao utilizao do UDP so o aumento da segurana e da confiabilidade na comunicao entre o autenticador e o servidor de autenticao, ou entre os servidores de autenticao, no caso de um sistema de autenticao hierrquico, como o do eduroam. Este considerado mais crtico, j que a comunicao entre servidores RADIUS de instituies distintas implica o trfego dos dados de autenticao em redes administradas por entidades diversas.
107
Captulo 7 - RadSec: Segurana na comunicao RADIUS
Deficincias na segurana do RADIUS

11 O padro RADIUS no to seguro. 11 No RADIUS, os pares so reconhecidos atravs de seu IP e do conhecimento de senhas compartilhadas, usadas em conjunto com um resumo criptogrfico (hash) MD5. 22 O MD5 fraco. 22 Alguns atributos so transmitidos em texto-puro. 11 Soluo em duas partes: 11 Entre autenticador e servidor: utilizar EAPTLS, EAP-TTLS ou EAP-PEAP. 11 Entre servidores (esquema de proxy): utilizar o RadSec. O padro RADIUS apresenta algumas deficincias em sua segurana. Em primeiro lugar, a autenticao de servidores e de clientes RADIUS (autenticadores) baseada nos endereos IP desses elementos e em senhas pr-compartilhadas (segredos), configuradas
nesses dispositivos. As senhas no so usadas diretamente, mas utilizadas para o clculo de resumos criptogrficos gerados pelo algoritmo MD5. Ocorre que, como veremos, o MD5 um algoritmo fraco. Alm disso, mesmo esse esquema falho usado apenas para proteger partes da comunicao RADIUS (como senhas de usurios, por exemplo), sendo o restante da mensagem transmitido sem qualquer proteo. Como soluo, indicado que, primeiramente, sejam utilizados mtodos EAP seguros durante o encaminhamento das mensagens entre cliente (autenticador) e servidor RADIUS, como o EAP-TTLS, EAP-TLS ou EAP-PEAP. Alm disso, para proteger o trfego entre os servidores de uma federao como a do eduroam, sugere-se a adoo do RadSec.
Saiba mais
Existem ainda outras deficincias no padro RADIUS. Para conhecer mais sobre os possveis ataques ao RADIUS: http://www.untruth. org/~josh/security/ radius/radius-auth.html
Vulnerabilidades do MD5
O resumo criptogrfico MD5 possui vulnerabilidades publicadas. 11 Coliso: possvel encontrar duas mensagens M1 e M2, que produzem o mesmo
resumo criptogrfico (hash). 11 Coliso com prefixo determinado: possvel acrescentar contedo ao final de uma mensagem M1, de forma a gerar o mesmo resumo da mensagem M2. J so bem conhecidos os problemas de segurana do resumo criptogrfico MD5. Com computadores j ultrapassados (Pentium 4) possvel encontrar colises de uma mensagem em poucos segundos. Alm disso, so tambm conhecidos ataques de coliso com prefixo determinado, onde o atacante acrescenta contedo ao final de uma mensagem de forma a gerar o mesmo resumo criptogrfico de outra mensagem.
108
Vantagens do RadSec
11 TLS entre as comunicaes RADIUS. 11 O mtodo obrigatrio de autenticao entre os servidores o uso de Certificados X.509. 11 Cada servidor RADIUS tem seu certificado. 11 Alto nvel de criptografia. 22 Criptografa toda a mensagem. 11 Utiliza TCP e no mais UDP. 22 Transporte confivel. 22 Porta 2083. No padro RadSec, o mtodo obrigatrio de autenticao o uso de certificados X.509,
que permitem a criao de uma comunicao segura e mutuamente autenticada. Opcionalmente, podem ser implementadas autenticaes com fingerprints dos certificados ou com senhas pr-compartilhadas. Considera-se esse modelo de segurana forte, uma vez que prov alto nvel de criptografia. Todo o contedo da mensagem criptografado antes de ser enviado ao servidor RADIUS de destino, e vice-versa. Outra vantagem diz respeito utilizao do TCP em vez do UDP. Um dos primeiros ganhos a confiabilidade na transmisso das mensagens, funcionalidade nativa do protocolo de transporte TCP. A porta TCP padronizada para o RadSec a 2083.
Compatibilidade RADIUS UDP vs RadSec

Um servidor RadSec deve ser capaz de receber conexes e se comunicar com servidores legados (RADIUS-UDP). As mensagens enviadas pelo RadSec so as mesmas do protocolo RADIUS. 11 Access-Request, Accounting-Request etc. O RadSec foi proposto como um perfil de comunicao a ser utilizado por servidores RADIUS. Por isso, um servidor que utiliza RadSec deve ainda ser capaz de operar da forma tradicional, no criptogrfica, utilizando o protocolo UDP, como o RADIUS tradicional. Alm disso, o contedo das mensagens enviadas no protocolo RADIUS no alterado pelo RadSec. Isso significa que as mensagens possuem os mesmos tipos (Access-Request, Accounting-Request etc).
109
Autenticao com RadSec

1
2 Nvel Federao 1 Nvel Institucional instituto.br
RadSec Proxy RADIUS RadSec Proxy Federao: RadSec Proxy
Figura 7.1 Processo de autenticao com RadSec para um usurio em roaming.
universidade.br
RADIUS
Ponto de Acesso
Servidor LDAP Federao: RadSec Proxy
Servidor LDAP
2
2 Nvel Federao 1 Nvel Institucional
instituto.br
RadSec Proxy RADIUS RadSec Proxy
universidade.br
RADIUS
Ponto de Acesso
Servidor LDAP

RadSec Proxy RADIUS RadSec Proxy RADIUS
universidade.br
Ponto de Acesso
Servidor LDAP
Servidor LDAP
110
Estabelecimento de sesso TLS sobre TCP
Federao: RadSec Proxy

RadSec Proxy RadSec Proxy
universidade.br
RADIUS
RADIUS
Ponto de Acesso
Servidor LDAP
Servidor LDAP
5
Ca113kfsndvasdcsdkbm Federao: RadSec Proxy

RadSec Proxy RadSec Proxy
universidade.br
RADIUS
RADIUS
Ponto de Acesso
Servidor LDAP
2 Nvel Federao
1 Nvel Institucional instituto.br
RadSec Proxy RadSec Proxy RADIUS
universidade.br
RADIUS
Ponto de Acesso
Servidor LDAP
Servidor LDAP
111
A Figura 7.1 ilustra um pedido de autenticao de um usurio em roaming enviado com o uso do RadSec para comunicao segura entre o servidor da instituio visitada (UFRJ, no exemplo) e o servidor da federao e, ainda, entre o servidor da federao e o servidor da instituio de origem (UFF, no exemplo), atravs de conexes TCP/TLS. Observem que o uso de RadSec indicado para aumentar o nvel de segurana na comunicao entre servidores eduroam, entretanto, no obrigatrio. Como a troca de mensagens ocorre entre o servidor da federao e o servidor de cada instituio, em uma mesma federao, algumas instituies podem utilizar RADIUS e outras podem utilizar o RadSec.
Implementaes
11 Radiator: 11 Implementao comercial do RADIUS. 11 radsecproxy : 22 Implementao gratuita. 22 Pode ser usado em conjunto com o FreeRADIUS.
Atualmente h duas implementaes do RADIUS sobre TLS. A primeira implementao, chamada Radiator, bastante difundida, porm paga. J a outra soluo, o radsecproxy, a mais utilizada atualmente no mbito do eduroam, por ser gratuita e compatvel com o FreeRADIUS.
O radsecproxy
11 FreeRADIUS pretende incorporar o padro RadSec futuramente. 11 As configuraes so feitas no arquivo radsecproxy.conf. O radsecproxy uma soluo de segurana para ser usada em conjunto com outros servi-
dores RADIUS, como o FreeRADIUS. No radsecproxy, tanto as configuraes de certificados, como os clientes autorizados e servidores proxy, ficam em um nico arquivo chamado radsecproxy.conf.
O desenvolvedor do FreeRADIUS, Alan Dekok, j manifestou a inteno de incorporar o padro RadSec ao servidor, eliminando a necessidade de instalao de software adicional, como o radsecproxy. Funcionamento do radsecproxy :
UDP
TC Ra P/ dS TL ec S
UDP
Figura 7.2 Comunicao interna do FreeRADIUS (UDP) e o encaminhamento pelo RadSec (TCP/TLS).
112
Alm da funo de proxy, como no padro RADIUS, o RadSec funciona como um proxy interno ao servidor local RADIUS. Isso acontece porque ele atua entre o encaminhamento e o recebimento dos pacotes RADIUS. Internamente (na mquina local), o RadSec funciona com UDP, mas s envia e recebe mensagens remotamente com TCP/TLS.
Comandos do radsecproxy
Comandos mais comuns: 11 Iniciando, encerrando e reiniciando o radsecproxy.
/etc/init.d/radsecproxy {start |stop |restart}

11 Iniciando o radsecproxy em modo debug (com mensagens exibidas no terminal):
radsecproxy f
Os principais comandos utilizados normalmente por um administrador so para iniciar, encerrar e reiniciar o radsecproxy. Existe a possibilidade de inicializ-lo no modo debug diretamente no terminal ou ainda executar o script de inicializao (start), paralizao (stop) e reinicializao (restart). Quando h um erro de sintaxe no arquivo de configurao radsecproxy.conf, a mensagem de erro genrica e no indica onde o problema ocorreu.
RADIUS Resumo dos dados utilizados nesta atividade prtica Federao
Arquivos editados Ponto de Servidor Servidor Acesso RADIUS Configurao geral do proxy RadSec. Neste arquivo so liberados os RADIUS 2 Instituio 2 clientes, criadas as entradas para os domnios, alm de configuradas Instituio /etc/radsecproxy.conf as portas e os certificados. Servidor Servidor LDAP RADIUS Liberao da comunicao RadSec com o local. 1 /etc/freeradius/clients.conf Instituio Instituio 1 FreeRADIUS Usurio Redirecionamento entre FreeRADIUS e RadSec. /etc/freeradius/proxy.conf
T Ra CP/ dS TL ec S -
Atividade Prtica 6 e Configurao do proxy com RadSec Servidor
Ponto de Acesso Servidor RADIUS Instituio 1 Servidor LDAP Instituio 1
Usurio
Figura 7.3 Ilustrao da prtica de configurao do RadSec.
A sexta atividade prtica tem como objetivo instalar o protocolo RadSec e configurar o servidor RADIUS de uma instituio e o servidor RADIUS da federao para habilitar a
113
STL P/ c TC dSe Ra STL P/ c TC dSe Ra
comunicao segura entre eles utilizando o RadSec. Trs arquivos so importantes: 11 Certificado da AC (ca.crt). 11 Certificado do servidor da instituio e sua senha associada (instituicao.crt). 11 Chave do certificado (instituicao.key).
Instalao do RadSec em cada instituio

Em distribuies baseadas em apt-get, como o caso do Ubuntu, que utilizamos para instalao do servidor RADIUS, necessrio apenas realizar o download e instalao do radsecproxy pelo comando a seguir.
apt-get install radsecproxy
Configurao do RadSec
Aps a instalao do pacote, vamos realizar a sua configurao. Por padro o arquivo de configurao nico e fica em /etc/radsecproxy.conf. Para o servidor de uma instituio, ele dever ter o contedo a seguir.
# Arquivo de configuracao do radsecproxy institucional # projeto eduroam-br # 2011-10-20
# Portas usadas na autenticacao da instituicao local (ex: realm @ uff.br) # Recebe mensagem do radsecproxy da Federacao atraves de TLS
listenTLS
*:2083
# e repassa mensagem para o radius local SourceUDP *:33000
# Portas usadas na autenticacao remota (outras instituicoes) # Recebe as mensagens do radius local na porta 1830 ListenUDP *:1830
# e repassa mensagem para o radsecproxy da Federacao (TLS) SourceTLS *:33001
# Nivel de debug, 3 eh o padrao, 1 eh o menor e 4 o maior LogLevel 4
114
# Arquivo de log LogDestination file:///var/log/radsecproxy.log
# Configuracao de certificado tls default { CACertificateFile CertificateFile CertificateKeyFile /etc/freeradius/certs/instituicoes/ca.crt /etc/freeradius/certs/instituicoes/uff.crt /etc/freeradius/certs/instituicoes/uff.key
certificateKeyPassword SENHA_DO_CERTIFICADO }
# Excluindo TAG de VLAN rewrite defaultclient { removeAttribute removeAttribute removeAttribute } 64 65 81
# Autenticacao na instituicao local # Recebe as conexoes TLS vindas do radsecproxy da Federacao... client 200.20.10.88 { host 200.20.10.88 type tls secret Senha_Compartilhada_Federao certificateNameCheck off }
# ... e repassa para o radius da propria maquina (local) server 127.0.0.1 { host historico.uff.br type udp secret Senha_Compartilhada_Local
115
port 1812 }
# Autenticacao em outras instituicoes # Recebe as conexoes vindas do radius local... client 127.0.0.1 { host 127.0.0.1 type udp secret Senha_Compartilhada_Local certificateNameCheck off }
# ... e repassa para o radsecproxy da Federacao (TLS) server 200.20.10.88 { host moreninha.midiacom.uff.br type tls secret Senha_Compartilhada_Federao StatusServer on }
# Configuracao dos realms. # Se o realm for da instituicao, manda para servidor radius local; # Caso contrario, repassa mensagem para servidor radius da federacao. # Para ter redundancia, pode-se configurar 2 servidores radius e descomentar as linhas abaixo
realm uff.br { server 127.0.0.1 }
116
realm * { server 200.20.10.88 accountingServer 200.20.10.88 }
Instalao do certificado
Como pode ser visto no contedo do arquivo radsecproxy.conf, necessrio ter os certificados instalados no servidor para que a comunicao segura via TLS seja estabelecida. Sendo assim, necessrio salvar o certificado da instituio e a chave do certificado da instituio, assim como o certificado da AC (Autoridade Certificadora) da federao em uma subpasta (no exemplo do arquivo radseproxy.conf, essa pasta se chama instituicoes e fica em /etc/freeradius/certs/ ). Outro passo necessrio para que a AC que gerou o certificado seja confivel pelo servidor em que o RadSec est sendo instalado indicado a seguir.
mkdir /usr/share/ca-certificates/eduroam
sudo cp /etc/freeradius/certs/ca.crt /usr/share/ca-certificates/ eduroam
sudo dpkg-reconfigure ca-certificates

Aps abrir a tela de seleo de certificados de AC confiveis, o arquivo ca.crt, que foi adicionado, deve ser marcado. Assim sero atualizados todos os ndices e a AC da federao, que gerou o certificado da instituio, ser considerada como confivel.
Configurao do FreeRADIUS
necessrio uma simples e pontual mudana no arquivo proxy.conf do FreeRADIUS, como indicado a seguir.
home_server eduroam-br { type ipaddr #ipaddr #port port ...

A linha que realiza o encaminhamento direto para o servidor da federao (200.20.10.88:1812) deve ser comentada, pois agora o encaminhamento ser feito pelo proxy RadSec (127.0.0.1:1830). Testes com radtest podem ser realizados, e analisados os logs do FreeRADIUS e do RadSec,
= auth+acct = 127.0.0.1 = 200.20.10.88 = 1812 = 1830
117
disponveis no arquivo /var/log/radsecproxy.log. Para iniciar o RadSec, o seguinte comando deve ser utilizado.
/etc/init.d/radsecproxy start
Gerao de certificados
Os certificados, que sero utilizados com o protocolo RadSec, podem ser gerados pelo servidor da federao. Para isso, necessria a criao de uma Autoridade Certificadora (AC). Este passo ser realizado somente pelo professor em um sua mquina e se encontra exposto somente como guia de referncia. Para a criao de uma AC, necessria a instalao do OpenSSL no servidor da federao.
apt-get install openssl

Em seguida, necessrio criar uma base de dados para a AC.
cd /etc/freeradius/certs/ echo 01 > serial touch index.txt

O prximo passo configurar o arquivo de gerao da AC. Esse arquivo ser tambm utilizado no momento da assinatura dos certificados das instituies. Podemos visualizar o contedo desse arquivo a seguir.
[ ca ] default_ca = CA_default
[ CA_default ] dir
= ./ = $dir/serial = $dir/index.txt = $dir = $dir/ca.crt = $dir/ca.key = 365 = md5 = no = no = default_ca = default_ca = policy_anything
serial database new_certs_dir certificate private_key default_days default_md preserve email_in_dn nameopt certopt policy
118
[ policy_match ] countryName stateOrProvinceName organizationName organizationalUnitName commonName emailAddress = match = match = match = optional = supplied = optional
[ policy_anything ] countryName stateOrProvinceName localityName organizationName organizationalUnitName commonName emailAddress = optional = optional = optional = optional = optional = supplied = optional
[ req ] prompt distinguished_name default_bits input_password output_password #x509_extensions x509_extensions = no = certificate_authority = 2048 = SENHA_DO_CERTIFICADO = SENHA_DO_CERTIFICADO = v3_ca = v3_req
[ req_distinguished_name ] # Variable name #------------------------0.organizationName organizationalUnitName emailAddress Prompt string ---------------------------------= UFF = Midiacom = esilva@ic.uff.br
119
emailAddress_max localityName stateOrProvinceName countryName countryName_min countryName_max commonName commonName_max
= 40 = Niteroi = Rio de Janeiro = BR = 2 = 2 = moreninha.midiacom.uff.br = 64
# Default values for the above, for consistency and less typing. # Variable name #-----------------------0.organizationName_default localityName_default stateOrProvinceName_default countryName_default Value -----------------------------= UFF = Niteroi = Rio de Janeiro = BR
[certificate_authority] countryName stateOrProvinceName

= BR = RJ = Niteroi = UFF = esilva@ic.uff.br = IP ou nome da mquina do Professor
localityName organizationName emailAddress commonName [v3_ca] subjectKeyIdentifier authorityKeyIdentifier basicConstraints extendedKeyUsage
= hash = keyid:always,issuer:always = CA:true = serverAuth, clientAuth
[ v3_req ] basicConstraints = CA:FALSE subjectKeyIdentifier = hash
120
extendedKeyUsage
= serverAuth, clientAuth
Como conveno, a partir deste momento, usaremos o contedo da Tabela 7.1 para a nomenclatura das extenses dos arquivos criados durante o processo de gerao de certificados. Extenso .cnf .csr
Tabela 7.1 Extenses de arquivos.
Definio Arquivo de configurao do certificado. Requisio de gerao de certificado. Chave do certificado. Certificado.
.key .crt
Vamos agora criar o certificado raiz de nossa AC. Ateno para a validade do certificado, que neste exemplo de apenas 365 dias.
openssl req -new -x509 -extensions v3_ca -keyout ca.key -out ca.crt -days 365 -config ./ca.cnf
Veja a seguir como criar o arquivo .cnf para o cliente (instituio exemplo: UFF).
[ ca ] default_ca = CA_default
[ CA_default ] dir certs crl_dir database new_certs_dir certificate serial crl private_key RANDFILE name_opt cert_opt default_days default_crl_days default_md preserve = ./ = $dir = $dir/crl = $dir/index.txt = $dir = $dir/server.pem
= $dir/serial = $dir/crl.pem = $dir/server.key = $dir/.rand = ca_default = ca_default = 1825 = 30 = md5 = no
121
policy
= policy_match
[ policy_match ] countryName stateOrProvinceName organizationName organizationalUnitName commonName emailAddress = match = match = match = optional = supplied = optional
[ policy_anything ] countryName stateOrProvinceName localityName organizationName organizationalUnitName commonName emailAddress = optional = optional = optional = optional = optional = supplied = optional
[ req ]
prompt distinguished_name default_bits input_password output_password x509_extensions
= no = uff = 2048 = SENHA_DO_CERTIFICADO = SENHA_DO_CERTIFICADO = v3_ca
[uff] countryName stateOrProvinceName localityName organizationName emailAddress = BR = RJ = Niteroi = Nome da Instituio = admin@eduroam.br
122
commonName
= IP da mquina da instituio ou FQDN
[v3_ca] subjectKeyIdentifier authorityKeyIdentifier basicConstraints extendedKeyUsage = hash = keyid:always,issuer:always = CA:true = serverAuth, clientAuth
Em seguida, necessrio gerar o certificado da instituio com base no .cnf.
openssl req -new -nodes -out instituicoes/uff.csr -keyout instituicoes/uff.key -config ./uff.cnf
openssl ca -out instituicoes/uff.crt -config ./ca.cnf -infiles instituicoes/uff.csr

O certificado gerado e a chave desse certificado devem ser enviados instituio correspondente.
Configurao do servidor da federao

O contedo do arquivo proxy.conf do servidor da federao ilustrado a seguir.
# LATLR home_server eduroam-la { type = auth+acct

ipaddr = 127.0.0.1 port = 1830 secret = SENHA_COMPARTILHADA_FEDERACAO require_message_authenticator = no response_window = 20 zombie_period = 5 revive_interval = 20 status_check = status-server check_interval = 30 num_answers_to_alive = 3
123
coa { irt = 2 mrt = 16 mrc = 5 mrd = 30 } }
home_server_pool LATLR { type = fail-over home_server = eduroam-la }
realm DEFAULT { auth_pool = LATLR acct_pool = LATLR nostrip }
realm LOCAL { }
realm NULL { secret = SENHA_COMPARTILHADA_FEDERACAO }
#INSTITUICOES # UFF realm uff.br { authhost secret nostrip = 127.0.0.1:1830 = SENHA_COMPARTILHADA
124
# UFRJ Realm ufrj.br { authhost secret nostrip }

Vamos ento s configuraes de entradas para o arquivo radsecproxy.conf, referente ao RadSec. nesse arquivo que realmente sero inseridas as entradas para os domnios e a confederao, assim como a liberao das requisies vindas dos clientes (servidores das instituies e confederao).
= 127.0.0.1:1830 = SENHA_COMPARTILHADA
# Arquivo de configuracao do radsecproxy da federacao # Recebe mensagem dos radsecproxies instituicionais atraves de TLS listenTLS *:2083
# e repassa mensagem para os radsecproxies destinos SourceTLS *:33001
## e repassa mensagem para o radius local SourceUDP *:33000
## Portas usadas na autenticacao remota (outras instituicoes) ## Recebe as mensagens do radius local na porta 1830 ListenUDP *:1830
# Nivel de debug, 3 eh o padrao, 1 eh o menor e 4 o maior LogLevel 4
# Arquivo de log LogDestination file:///var/log/radsecproxy.log
# Prevencao contra looping LoopPrevention On
125
# # Configuracao de certificado tls default { CACertificateFile CertificateFile CertificateKeyFile /etc/freeradius/certs/ca.crt /etc/freeradius/certs/federacao.crt /etc/freeradius/certs/federacao.key
certificateKeyPassword SENHA_CERTIFICADO }
# Remove TAG da VLAN rewrite defaultclient { removeAttribute removeAttribute removeAttribute } 64 65 81
# Recebe as conexoes TLS vindas dos radsecproxies institucionais # Cliente UFF client 200.20.0.XX { host
eduroam.uff.br TLS SENHA_COMPARTILHADA
type secret
certificateNameCheck off }
client 127.0.0.1 { host type secret } 127.0.0.1 UDP SENHA_COMPARTILHADA
# ... e repassa para o radius da instituicao destino
126
server uff.br { host eduroam.midiacom.uff.br type TLS secret SENHA_COMPARTILHADA statusserver on certificateNameCheck off }
# SERVIDOR CONFEDERACAO server LATLR { host 200.37.WW.UU type TLS secret SENHA_COMPARTILHADA_CONFEDERACAO statusserver on }
server ufms.br { host radius.ufms.br type TLS secret SENHA_COMPARTILHADA_UFMS statusserver on }
# Realm conhecidos e da confederao, para aqueles no conhecidos. realm uff.br { server uff.br }
realm * { server LATLR }
127
128
8
RADIUS Accounting: conceitos e finalidade
objetivos
Compreender a finalidade e operao bsica de um sistema de contabilizao (accounting) de acesso baseado no padro RADIUS. Adquirir conhecimentos bsicos sobre a instalao e configurao do sistema de contabilizao do RADIUS com base de dados auxiliar.
conceitos
Accounting, mensagens de accounting e o encaminhamento destas atravs de um servidor proxy.
Introduo
11 Padro RADIUS original era apenas AA (Autenticao e Autorizao). 11 RADIUS Accounting foi introduzido pela RFC 2059 de 1997 e atualizado pelas RFCs 2139 e 2866 (de 2000). 11 Utiliza a porta 1813 (UDP), portanto uma porta diferente da usada para autenticao. 11 Finalidade do accounting: 22 F ornecer informaes sobre a autenticao de um usurio.
e rlogin). 11 Possibilidade de: 22 Monitoramento e coleta de estatsticas. 22 Cobrana por utilizao. Introduzido em 1997, o RADIUS Accounting surgiu para complementar o padro RADIUS. At ento o padro RADIUS provia apenas as funcionalidades de autenticao e autorizao. Com essa extenso, foi possvel prover o triplo A (Autenticao, Autorizao e Accounting AAA). Por padro, utiliza-se a porta UDP 1813 para envio das mensagens, ou seja, uma porta diferente da usada para autenticao. A RFC original, RFC 2059, foi atualizada pelas RFCs 2139 e 2866, esta ltima de junho de 2000.
129
Captulo 8 - RADIUS Accounting: conceitos e finalidade
22 Facilitar a contabilidade de utilizao de usurios (originalmente em PPP, telnet
Esse padro surgiu com a finalidade de fornecer informaes sobre os eventos de auten ticao de usurios, consequentemente facilitando o acompanhamento com relao aos pedidos gerados por um cliente. Como exemplo dessa funcionalidade, possvel extrair informaes como o status da autenticao, se essa foi realizada com sucesso ou no e em qual autenticador (Ponto de Acesso em nosso contexto) o usurio est se associando. Alm de levantar estatsticas sobre os eventos de autenticao de usurios, atravs do RADIUS accounting tambm possvel determinar o tempo de conexo de um usurio e registrar dados como quantidade de pacotes e bytes consumidos.
RADIUS Accounting
11 Segue o mesmo padro cliente-servidor do RADIUS. 11 Autenticador (cliente RADIUS) responsvel por solicitar o registro e tambm por encaminhar as informaes de accounting ao servidor RADIUS. 11 Servidor RADIUS accounting deve apenas responder ao autenticador com mensagem indicando sucesso ou no no atendimento da requisio. 11 A segurana provida pela mesma senha compartilhada pelo mtodo de autenticao (shared secret). O RADIUS accounting um complemento ao padro j existente at ento e, portanto, segue o modelo cliente-servidor j utilizado pelo RADIUS. O autenticador deve solicitar ao servidor RADIUS que inicie o registro de certa mtrica. O autenticador tambm responsvel por enviar posteriormente os dados a serem arma-
zenados, como veremos em um exemplo adiante. O servidor de autenticao deve sempre sinalizar se as requisies foram ou no atendidas, atravs de mensagens de sucesso ou falha. A segurana, por padro, fornecida pelo mesmo mtodo utilizado na comunicao entre autenticador e servidor RADIUS (senha compartilhada + hash MD5), ou seja, por meio de senha compartilhada (lembrando que essa senha nunca enviada pela rede e sim confi gurada manualmente pelo administrador em ambos os equipamentos). Tambm possvel utilizar o RadSec como suporte a esse envio das mensagens de contabilidade. Sendo assim,
a segurana a ser fornecida fica apoiada no TLS, como veremos mais detalhadamente a seguir.
Accounting e RadSec
11 No RadSec, todas as operaes so realizadas na mesma porta TCP (2083). 11 No existem portas distintas para autenticao/autorizao e contabilizao. 11 Se o servidor RadSec no estiver configurado para accounting, ele deve sinalizar tal fato ao requisitante.
Quando o RadSec usado, no haver uma porta separada para o RADIUS accounting. Essa funcionalidade implementada na mesma porta TCP usada pelo RadSec para as funes de autenticao e autorizao (porta 2083). Se o servidor RadSec em questo no estiver configurado para realizar contabilizao, ele deve, mesmo assim, responder aos pedidos de accounting, enviando uma mensagem Accounting-Response contendo o atributo Error-Cause com o valor 406 Unsupported Extension (causa do erro: extenso no suportada).
130
Mensagens de accounting
0 Code 7 Identier 15 Length 31
Figura 8.1 Formato da mensagem de accounting do RADIUS .
Authenticator
Attribute O RADIUS Accounting utiliza dois tipos de mensagem. A mensagem de solicitao de contabilizao, Accounting-Request (tipo 4) e a mensagem de resposta a essa solicitao, Accounting-response (tipo 5). Essas mensagens seguem o mesmo formato das mensagens do RADIUS (exemplo: Access-Request). 11 Accounting-Request a mensagem de solicitao ao servidor no incio, na finalizao e na atualizao de status intermediariamente contabilizao. 11 Accounting-Response a mensagem responsvel por informar ao autenticador que o Access-Request foi recebido e armazenado com sucesso.
Atributos das mensagens de accounting

As mensagens de Accounting-Request possuem atributos com informaes particulares, assim como identificadores de incio e fim da gravao de uma sesso. Sero descritos, portanto, alguns desses atributos como forma ilustrativa, tratando com mais detalhes mais frente o atributo Acct-Status-Type. 11 Acct-Status-Type: indica o incio, o fim e se a sesso se encontra ativa. 11 Acct-Delay-Time: o atributo responsvel por indicar quanto tempo o autenticador tem para enviar uma mensagem de status ao servidor. Caso no seja recebida uma mensagem nesse tempo determinado, uma requisio (Accounting-Request) pode ser utilizada para solicitar tal informao ao autenticador. 11 Acct-Session-Id: o atributo que identifica uma sesso. A partir desse atributo a admi nistrao de um registro de incio e fim de uma sesso se torna mais simples, uma vez que ambos possuem o mesmo valor.
11 Acct-Session-Time: indica o tempo em que o usurio esteve associado. Responsvel pela contabilizao do tempo total de uso, esse atributo estar presente somente quando a sesso for finalizada. 11 Acct-Input-Packets: carrega a informao de quantos pacotes foram recebidos atravs da porta associada ao usurio no autenticador. Esse atributo tambm serve para contabilizao do uso dos recursos da rede e enviado somente ao final da sesso pelo autenti cador ao servidor. 11 Acct-Output-Packets: carrega a informao de quantos pacotes foram transmitidos para a porta associada ao usurio no autenticador. Assim como Acct-Input-Packets, esse atributo tambm serve para contabilizao do uso dos recursos da rede e enviado somente ao final da sesso pelo autenticador ao servidor
131
1 Tipo
7 Tamanho
15
31 Valor
Valor (cont)
Figura 8.2 Formato da mensagem de atributos do accounting.
Os atributos podem depender do fabricante. Alguns produtos podem fornecer informaes de forma diferente de outros.
Atributos Acct-Status-Type
Responsvel por informar o status da sesso (incio, fim ou ativa):
Type
40 for Acct-Status-Type. Length 6 Value (8 octetos) 1 Start 2 Stop 3 Interim-update ...
O atributo Acct-Status-Type o mais importante atributo para a funcionalidade de accounting.

Ele tem a finalidade de informar ao servidor RADIUS Accounting o incio, o fim de uma sesso e se esta ainda se encontra ativa. Para acompanharmos como realizada a troca de mensagens e o funcionamento do accounting, a Figura 8.3 mostra um exemplo de uma criao, manuteno e finalizao de sesso.
132
Troca de mensagens
Autenticador RADIUS: Accounting-Request (4) [acct_status_type=start] Servidor RADIUS
RADIUS: Accounting-Response (5)
RADIUS: Accounting-Request (4) [acct_status_type=interim update]
RADIUS: Accounting -Response (5)

Figura 8.3 Troca de mensagens entre o autenticador e o servidor RADIUS para accounting.
RADIUS: Accounting-Request (4) [acct_status_type=stop]
RADIUS: Accounting -Response (5)
Quando um acesso concedido a um suplicante pelo autenticador, este envia ao servidor RADIUS accounting um sinal de start (uma mensagem do tipo Accounting-Request com atributo Acct-Status-Type = start). Esse pacote, tipicamente, contm a identificao do usurio, o endereo de rede, a identificao do NAS e um identificador nico de sesso. A fim de informar ao servidor RADIUS accounting que a conexo continua ativa, enviada periodicamente uma nova mensagem do tipo interim update (um pacote do tipo Accounting-Request com atributo Acct-Status-Type = interim-update). Usualmente com o tempo atual da sesso do cliente e a data. Quando o acesso finalizado, o autenticador envia um sinal do tipo stop (uma men sagem do tipo Accounting-Request com atributo Acct-Status-Type = stop). Onde, alm da informao de finalizao do registro de contabilizao, geralmente carrega informaes do tempo, dados transferidos e motivo da desconexo. Como dissemos, cada mensagem enviada pelo servidor RADIUS. Essa mensagem funciona como uma confirmao de rece bimento (um ACK).
Accounting-Request deve ser respondida por uma mensagem Accounting-Response,
Accounting e roaming
O encaminhamento das mensagens de accounting via proxy realizado da mesma forma como feito o encaminhamento das mensagens de autenticao. O proxy insere (quando encaminha a outro servidor) ou retira (quando recebe de outro servidor) o ltimo atributo Proxy-State. Opcionalmente, os servidores de encaminhamento podem registrar os dados de contabilizao por ele repassados. Nesse caso, se considerarmos o servio eduroam, os dados podero ser registrados tanto pela instituio de origem como pela instituio visitada.
133
Atividade Prtica 7 e Configurao do accounting e banco de dados PostgreSQL

Resumo dos dados utilizados nesta atividade prtica Usurio administrador da base de dados. Senha do usurio administrador da base de dados. Senha compartilhada entre o servidor RADIUS da instituio (aluno) e o RADIUS da federao (professor). Arquivos editados Liberao para acesso base de dados. Arquivo SQL com a estrutura de tabelas para o RADIUS. Arquivo de comunicao entre o FreeRADIUS e o PostgreSQL. Arquivo de habilitao do mdulo de Accounting no FreeRADIUS. /etc/postgresql/8.4/main/pg_hba.conf /etc/freeradius/sql/postgresql/schema.sql /etc/freeradius/sql.conf /etc/freeradius/sites-enable/inner-tunnel (padro) Ou se voc seguiu o tutorial e criou um arquivo novo, chamado eduroam /etc/freeradius/sites-enable/eduroam Liberao do carregamento do mdulo SQL. Arquivo com a query responsvel pelo armazenamento das respostas e requisies. /etc/freeradius/radiusd.conf /etc/freeradius/sql/postgresql/diaulup.conf /etc/phppgadmin/apache.conf Configurao do acesso interface do phppgadmin. Ou /etc/apache2/conf.d/phppgadmin RADIUS RADIUS Usualmente: eduroam123
STL P/ c TC dSe Ra
Ponto de Acesso
Relatrios
Servidor RADIUS Instituio 2 Servidor RADIUS Instituio 1 Servidor LDAP Instituio 1
Usurio
A stima e ltima prtica tem como objetivo configurar a funcionalidade de accounting (contabilizao) dos pedidos de autenticao no RADIUS atravs do uso de uma base de dados relacional utilizando o PostgreSQL, possibilitando maior controle sobre o uso do servio eduroam em uma instituio de ensino e pesquisa.
Instalao e configurao do suporte ao accounting

O accounting fornece informaes muito importantes para o controle de acesso e posterior anlise dos usurios. Somente com o accounting ser possvel o administrador descobrir
Figura 8.4 Indicao da prtica, configurao da gerao de relatrios no servidor RADIUS da instituio.
134
a qual usurio um certo IP estava associado em um dado momento. relevante tambm destacar que nem todos os pontos de acessos realizam o tratamento dos pacotes referentes ao accounting (Accounting-Request e Accounting-Response), assim como os diversos atributos disponveis.
Instalao do PostgreSQL
A instalao do banco de dados PostgreSQL simples e necessita de pouca configurao para que esteja em funcionamento. Sendo assim, necessrio realizar apenas os passos indicados a seguir.
# apt-get install postgresql-8.4 # su - postgres # psql -c ALTER USER postgres WITH PASSWORD novasenha
Caso deseje adicionar algum IP para a administrao remota da base de dados, verifique o arquivo contido em /etc/postgresql/8.4/main/pg_hba.conf. Recomendamos adicionar tambm o contedo indicado a seguir, que representa a liberao do usurio radius localmente base denominada radius (que futuramente ser criada).
local
radius
radius md5
Aps a instalao do banco de dados, passamos etapa de criao da base de dados utilizada pelo FreeRADIUS para o accounting, como ser exposto a seguir.
Configurando FreeRADIUS para accounting

Como primeiro passo, caso o FreeRADIUS tenha sido instalado em uma distribuio com base em pacotes (exemplo: Ubuntu ou Debian), necessrio apenas instalar o pacote com as informaes e mdulos necessrios ao acesso SQL.
# apt-get install freeradius-postgresql

O prximo passo, depois de instalado o suporte ao banco de dados, criar o usurio radius, que administrar a base de dados chamada radius. A base de dados radius vai conter todas as tabelas necessrias para que o sistema de accounting funcione.
# su - postgres # createuser radius --no-superuser --no-createdb --no-createrole -P # createdb radius --owner=radius # exit
Os arquivos relacionados ao accounting se encontram na pasta /etc/freeradius/sql/postgresql e, a partir de um dos arquivos l presentes, sero criadas as tabelas referentes base de dados radius criada, como indicado a seguir.
# cd /etc/freeradius/sql/postgresql/ # psql -U radius W d radius h 127.0.0.1 f schema.sql

Sendo: 11 -U usurio. 11 -W para pedir a senha do usurio.
135
11 -d o nome da base de dados. 11 -h o endereo do host postgres. 11 -f o arquivo de importao. Neste momento, j temos tanto a base de dados como o usurio que a administrar criados e configurados. Ento, devem-se configurar os arquivos referentes ao FreeRADIUS para habilitar a gravao no banco de dados. Os arquivos do FreeRADIUS que devero ser alterados so: 11 /etc/freeradius/sql.conf 11 /etc/freeradius/sites-enabled/default 11 /etc/freeradius/sites-enabled/eduroam ou inner-tunnel 11 /etc/freeradius/radiusd.conf 11 /etc/freeradius/sql/postgresql/dialup.conf No arquivo /etc/freeradius/sql.conf dever ser alterada apenas a senha do usurio radius e o endereo do servidor de banco de dados, como indicado a seguir.
sql { database = postgresql driver = rlm_sql_${database} server = localhost login = radius password = senha_do_usuario_radius_no_bd radius_db = radius ...
}
necessrio habilitar o accounting nos arquivos de configurao do FreeRADIUS, que j esto configurados em sua instalao. Esses arquivos so apresentados a seguir. Configurao dos arquivos /etc/freeradius/sites-enabled/default e /etc/freeradius/sites-enabled/ eduroam ou /etc/freeradius/sites-enabled/inner-tunnel.
... accounting { detail daily unix radutmp sql exec attr_filter.accounting_response
136
} ... session { radutmp sql } ... post-auth { ... sql ... } ...
Configurao do arquivo /etc/freeradius/radiusd.conf.
... modules { $INCLUDE ${confdir}/modules/ $INCLUDE eap.conf $INCLUDE sql.conf } ...

Para que sejam armazenadas as requisies e respostas de forma simultnea para solicitaes de autenticao dos usurios, necessrio realizar a configurao do arquivo /etc/freeradius/sql/postgresql/dialup.conf, conforme indicado a seguir.
... simul_count_query = SELECT COUNT(*) FROM ${acct_table1} WHERE UserName=%{SQL-User-Name} AND AcctStopTime IS NULL simul_verify_query = SELECT RadAcctId, AcctSessionId, UserName, NASIPAddress, NASPortId, FramedIPAddress, CallingStationId, FramedProtocol FROM ${acct_table1} WHERE UserName=%{SQL-User-Name} AND AcctStopTime IS NULL ...
Uso do phppgadmin para visualizar os dados coletados

Para facilitar a visualizao dos dados de accounting, pode-se utilizar o phppgadmin. Para isso, necessrio instalar o servidor web Apache com suporte ao PHP5.
137
# apt-get install apache2 # apt-get install libapache2-mod-php5 # apt-get install phppgadmin

Por padro, o phppgadmin aceitar somente conexes vindas da mquina local, portanto, caso deseje acessar a base de dados de outro computador pela interface web, aconselhamos que altere o arquivo localizado em /etc/phppgadmin/apache.conf como indicado a seguir. O mesmo arquivo pode j estar contido em /etc/apache2/conf.d/, com o nome de phpgadmin e, sendo assim, ser esse que dever ser alterado. Porm, caso exista apenas o arquivo /etc/phppgadmin/apache.conf, copie-o para /etc/apache2/conf.d/phppgadmin.
Alias /phppgadmin /usr/share/phppgadmin/ <Directory /usr/share/phppgadmin/> DirectoryIndex index.php Options +FollowSymLinks AllowOverride None order deny,allow deny from all allow from seu_ip/mascara #allow from 127.0.0.0/255.0.0.0 ::1/128 #allow from all <IfModule mod_php5.c> php_flag magic_quotes_gpc Off php_flag track_vars On
php_value include_path . </IfModule> </Directory>
# cp /etc/phppgadmin/apache.conf /etc/apache2/conf.d/phppgadmin
necessrio reiniciar o servidor web Apache para que as configuraes tenham efeito.
# /etc/init.d/apache2 restart
Para acessar a interface web do phppgadmin, utilize o navegador da mquina em que o acesso foi liberado e indique a URL http://maquina_servidor_postgresql/phppgadmin. Ser visualizada uma tela como a Figura 8.5. O acesso aos dados deve ser realizado pelo usurio RADIUS, que criamos durante a ativao do accounting.
138
Figura 8.5 Tela de acesso do phppgadmin.
Uma vez autenticado no sistema, dever ser selecionada a base de dados que desejamos administrar, no caso, a base chamada RADIUS. Como pode ser visto na Figura 8.6.
simples encontrar se um acesso foi negado ou aceito a um usurio em especial, e em qual momento isso ocorreu.
139
Figura 8.6 Seleo do banco de dados radius.
Os dados armazenados na tabela radpostauth equivalem resposta da solicitao de autenticao do cliente, e pode ser visualizada pela Figura 8.7. A partir desse relatrio,
Diversos dados podem ser habilitados para a coleta pelo accounting e armazenados no banco de dados, aumentando assim as possibilidades de controle e avaliao do ambiente RADIUS administrado.
Outras ferramentas de visualizao

11 freeradius-dialupadmin: tambm chamado de dial-up admin, baseado em PHP, gratuito e suporta consultas s bases de dados MySQL e PostgreSQL, ou ainda consulta direta base LDAP.
Figura 8.7 Relatrio de requisio de autenticao dos usurios.
Figura 8.8 Tela inicial do freeradiusdialupadmin.
11 Raptor : uma ferramenta baseada em software livre e de distribuio gratuita. um software voltado para visualizao de informao de accounting e autenticao, e muito utilizado para ambiente de provedor de identidade e de servios com uso do Shibboleth.
140
Figura 8.9 Tela capturada de visualizao de estatsticas para o Raptor.
H tambm a possibilidade de desenvolvimento de ferramentas especficas pelas institui es que fornecem o servio eduroam, fazendo consultas ao banco de dados utilizado para o armazenamento das informaes de accounting. Um exemplo a ferramenta desenvolvida pela equipe da Unicamp, instituio participante do piloto eduroam no Brasil.
Consideraes finais
Neste livro, apresentamos o servio eduroam, um servio de acesso sem fio seguro, baseado no conceito de federao e oferecido para a comunidade internacional de edu-
Assista ao vdeo demonstrativo Sistema para visualizao das informaes de accounting em: http:// www.youtube.com/ watch?v=ZQQSlEpE_qg.
cao e pesquisa. O eduroam um facilitador da colaborao entre alunos, professores e funcionrios das instituies acadmicas participantes da federao, pois permite a autenticao segura, o transporte seguro de dados em redes sem fio e a mobilidade de usurios entre instituies. Como vimos, seu funcionamento apoiado por uma srie de padres consagrados, como RADIUS, LDAP, IEEE 802.1X e IEEE 802.11i. Esperamos, com este livro e o respectivo curso da Escola Superior de Redes da RNP, ter contribudo para a sua adoo rpida e fcil em instituies de ensino e pesquisa no Brasil.
141
142
Bibliografia
11 GAST, M. 802.11: Wireless Networks: The Definitive Guide. 2nd Edition. Editora OReilly, 2005. 11 NAKHJIRI, M. AAA and Network Security for Mobile Access - RADIUS, DIAMETER, EAP, PKI and IP Mobility, ISBN 0470011947, Editora Wiley, 2005.
RFCs
11 [RFC 1994] PPP Challenge Handshake Authentication Protocol (CHAP) W. Simpson [August 1996] (Obsoletes RFC1334) (Updated-By RFC2484) (Status: DRAFT STANDARD). 11 [RFC 2865] Remote Authentication Dial In User Service (RADIUS) C. Rigney, S. Willens, A. Rubens, W. Simpson [ June 2000] (Obsoletes RFC2138) (Updated-By RFC2868, RFC3575, RFC 5080) (Status: DRAFT STANDARD). 11 [RFC 2759] Microsoft PPP CHAP Extensions, Version 2 G. Zorn [ January 2000] (Status: INFORMATIONAL). 11 [RFC 2798] Definition of the inetOrgPerson LDAP Object Class M. Smith [April 2000] (Updated-By RFC3698, RFC4519, RFC4524). 11 [RFC 2866] RADIUS Accounting C. Rigney [ June 2000] (Obsoletes RFC2139) (Updated-By RFC2867, RFC5080, RFC5997) (Status: INFORMATIONAL). 11 [RFC 3748] Extensible Authentication Protocol (EAP) B. Aboba, L. Blunk, J. Vollbrecht, J. Carlson, H. Levkowetz [ June 2004] (Obsoletes RFC2284) (Updated-By RFC5247) (Status: PROPOSED STANDARD). 11 [RFC 4510] Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map K. Zeilenga [ June 2006] (Obsoletes RFC2251, RFC2252, RFC2253, RFC2254, RFC2255, RFC2256, RFC2829, RFC2830, RFC3377, RFC3771) (Status: PROPOSED STANDARD). 11 [RFC 5216] The EAP-TLS Authentication Protocol D. Simon, B. Aboba, R. Hurst [March 2008] (Obsoletes RFC2716) (Status: PROPOSED STANDARD). 11 [RFC 6614] Transport Layer Security (TLS) Encryption for RADIUS S. Winter, M. McCauley, S. Venaas, K. Wierenga [May 2012] (Status: EXPERIMENTAL).
Bibliografia
143
Padres IEEE
11 [IEEE 802.11] IEEE Standard for Local and metropolitan area networks Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications. (2011 revision). 11 [IEEE 802.1X] IEEE Standard for Local and metropolitan area networks Port-Based Network Access Control (2010 revision).
144
Dbora Christina Muchaluat Saade professora associada do Departamento de Cincia da Computao da Universidade Federal Fluminense (UFF). engenheira de computao formada pela PUC-Rio e possui mestrado e doutorado em informtica pela mesma universidade. bolsista de produtividade em Desenvolvimento Tecnolgico e Extenso Inovadora pelo CNPq e foi Jovem Cientista do Estado do Rio de Janeiro pela Faperj. Suas reas de pesquisa so redes de computadores, redes sem fio, sistemas multimdia e hipermdia, TV digital interativa e telemedicina. J coordenou diversos projetos de pesquisa financiados pelo CNPq e Faperj e foi coordenadora do projeto piloto Eduroam-br, financiado pela RNP e realizado em parceria com a UFMS, UFRJ e diversas outras instituies, implantando o servio piloto eduroam no Brasil.
Ricardo Campanha Carrano engenheiro de telecomunicaes formado em 1995 pela Universidade Federal Fluminense. Em 2008, obteve o ttulo de Mestre em Engenharia de Telecomunicaes pela mesma instituio e atualmente cursa o doutorado em Computao, tambm na UFF, onde atua como Professor do Departamento de Engenharia de Telecomunicaes. Foi empresrio e participou da implantao de provedores de acesso no incio da Internet comercial no Brasil, em 1995. Atuou como Engenheiro de Redes para a ONG internacional One Laptop per Child (OLPC) e j participou de diversos projetos de pesquisa financiados pela RNP, pelo MEC e por empresas privadas.
Edelberto Franco Silva se tornou Bacharel em Sistemas de Informao pela Faculdade Metodista Granbery em 2006, e obteve o ttulo de Mestre em Computao pela Universidade Federal Fluminense em 2011. Atualmente Doutorando em Computao pela Universidade Federal Fluminense. Participou de diversos projetos de pesquisa, possuindo experincia na rea de Cincia da Computao, com nfase em redes, atuando principalmente nos temas relacionados a redes sem fio, Internet do Futuro e segurana.
LIVRO DE APOIO AO CURSO
O curso aborda os conhecimentos necessrios para a construo do ambiente de autenticao seguro e distriser capaz de integrar a sua instituio ao servio de acescao e pesquisa, permitindo que estudantes, pesquisadores e equipe de TI de instituies participantes acessem quando visitam outras instituies integradas ao servio. Este livro inclui os roteiros das atividades prticas e o contedo dos slides apresentados em sala de aula, apoiando suas organizaes ou localidades de origem.
ISBN 978-85-63630-25-4
9 788563 630254

Eduroam: Acesso Sem Fio Seguro para Comunidade Acadêmica Federada

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Eduroam: Acesso Sem Fio Seguro para Comunidade Acadêmica Federada

Hochgeladen von

Copyright:

Eduroam

Acesso sem fio seguro para Comunidade Acadmica Federada

Luiz Claudio Schara Magalhes

Luiz Claudio Schara Magalhes

Luiz Claudio Schara Magalhes

Rio de Janeiro Escola Superior de Redes 2013

Jos Luiz Ribeiro Filho

Escola Superior de Redes

Pedro Sangirardi Lincoln da Mata

Equipe ESR (em ordem alfabtica)

Escola Superior de Redes

2. Redes sem fio IEEE 802.11

4. RADIUS Viso geral e conceitos fundamentais

5. LDAP Viso geral e conceitos fundamentais

6. Roaming no eduroam: conceitos e funcionamento

Configurando o proxy da federao104 Teste de roaming106

7. RadSec: Segurana na comunicao RADIUS

8. RADIUS Accounting: conceitos e finalidade

Escola Superior de Redes

Convenes utilizadas neste livro

Servio eduroam, autenticao e roaming, Federao Acadmica.

Por favor, gostaria de acessar a rede?

Por favor, gostaria de acessar a rede?

Anote o login e a senha!

Anote o login e a senha!

4 jsilva senha123 jose.silva senha1234 silvaj 123senha

Por favor, gostaria de acessar a rede?

Por favor, gostaria de acessar a rede?

Voc j tem conta aqui, certo?

Figura 1.1 Problema de gesto a partir de bases completamente isoladas.

1224 EUROPE 763 3337 AFRICA

Tecnologias utilizadas no eduroam

Captulo 1 - Viso geral do eduroam

Figura 1.3 Logotipo da Comunidade Acadmica Federada.

Arquitetura IEEE 802.1X

servidor de autenticao, utilizado o protocolo RADIUS.

Comunidade Acadmica Federada

Autenticao na instituio de origem

inst2.edu.br Servidor RADIUS

inst2.edu.br Usurio em roaming

inst1.edu.br Servidor LDAP

inst2.edu.br Servidor LDAP

Figura 1.7 Disposio da hierarquia de servidores latino-americanos e servidores eduroam raiz.

Interconexo com Amrica Latina e Europa

Proxy LATLR CLARA .pe

Proxys ETLR GEANT

.nl .pe .br

Eduroam: acesso sem fio seguro para Comunidade Acadmica Federada

Redes IEEE 802.11

IEEE 802.11 e Wi-Fi

IEEE 802.11 arquitetura e modos de operao

Modos de operao: ad hoc

Modos de operao: infraestruturado

Componentes em redes ad hoc

Figura 2.1 Exemplo de uma rede ad hoc.

Componentes em redes infraestruturadas

Antena extensora de cobertura

Arquitetura: Basic Service Set

Arquitetura: Independent BSS

Figura 2.3 Exemplo de uma rede ad hoc, onde os ns se comunicam diretamente.

Arquitetura: infrastructure BSS

Adaptador Sem Fio (Carto)

Arquitetura: Extended Service Set

Antena extensora de cobertura

Figura 2.5 Exemplo de ligao/ extenso de duas redes sem fio.

Fluxo de dados em um ESS