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

Eduroam

Acesso sem fio seguro para Comunidade Acadêmica Federada Débora C. Muchaluat Saade Ricardo Campanha Carrano Edelberto Franco Silva Colaborador

Luiz Claudio Schara Magalhães

A RNP – Rede Nacional de Ensino e Pesquisa – é qualificada como uma Organização Social (OS), sendo ligada ao Ministério da Ciência, Tecnologia e Inovação (MCTI)

e

responsável

pelo

Programa Interministerial RNP, que conta com a participação dos ministérios da Educação (MEC), da Saúde (MS) e da Cultura (MinC). Pioneira no acesso à Internet no Brasil, a RNP planeja e mantém a rede Ipê, a rede óptica nacional acadêmica de alto desempenho. Com Pontos de Presença nas 27 unidades da federação, a rede tem mais de 800 instituições conectadas. São aproximadamente 3,5 milhões de usuários usufruindo de uma infraestrutura de redes avançadas para comunicação, computação e experimentação, que contribui para a integração entre o sistema de Ciência e Tecnologia, Educação Superior, Saúde e Cultura.

Ministério da Cultura Ministério da Saúde Ministério da Educação Ministério da Ciência, Tecnologia e Inovação

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada Débora C. Muchaluat Saade Ricardo Carrano Edelberto Franco Silva Colaborador

Luiz Claudio Schara Magalhães

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada Débora C. Muchaluat Saade Ricardo Carrano Edelberto Franco Silva Colaborador

Luiz Claudio Schara Magalhães

Rio de Janeiro Escola Superior de Redes 2013

Copyright © 2013 – Rede Nacional de Ensino e Pesquisa – RNP Rua Lauro Müller, 116 sala 1103 22290-906 Rio de Janeiro, RJ Diretor Geral

Nelson Simões Diretor de Serviços e Soluções

José Luiz Ribeiro Filho

Escola Superior de Redes Coordenação

Luiz Coelho Edição

Pedro Sangirardi Revisão

Lincoln da Mata Coordenação Acadêmica de Gestão de Identidade

Renato Duarte

Equipe ESR (em ordem alfabética)

Celia Maciel, Cristiane Oliveira, Derlinéa Miranda, Edson Kowask, Elimária Barbosa, Lourdes Soncin, Luciana Batista, Luiz Carlos Lobato, Sergio Ricardo de Souza e Yve Abel Marcial. Capa, projeto visual e diagramação

Tecnodesign Versão

1.1.0

Este material didático foi elaborado com fins educacionais. Solicitamos que qualquer erro encontrado ou dúvida com relação ao material ou seu uso seja enviado para a equipe de elaboração de conteúdo da Escola Superior de Redes, no e-mail [email protected]. A Rede Nacional de Ensino e Pesquisa e os autores não 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. Distribuição

Escola Superior de Redes

Rua Lauro Müller, 116 – sala 1103 22290-906 Rio de Janeiro, RJ http://esr.rnp.br [email protected]

Dados Internacionais de Catalogação na Publicação (CIP) S112e Saade, Débora Cristina M. Eduroam: Acesso Sem Fio Seguro para Comunidade Acadêmica Federada / Débora C. Muchaluat Saade, Ricardo Carrano, Edelberto Franco Silva; Colaborador Luiz Claudio Schara Magalhães. – 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 – Segurança. 2. Redes sem fio. 3. Autenticação. 4. Eduroam (education roaming). I. Carrano, Ricardo. II. Silva, Edelberto Franco. III. Título.

CDD 004.66

Sumário 1. Visão geral do eduroam Introdução 1 O projeto eduroam-br 3 Tecnologias utilizadas no eduroam 3 RADIUS 4 IEEE 802.11i 4 IEEE 802.1X 5 Arquitetura IEEE 802.1X 5 Comunidade Acadêmica Federada 5 Funcionamento do eduroam 6 Autenticação na instituição de origem 7 Interconexão com América Latina e Europa 7

2. Redes sem fio IEEE 802.11 Introdução 9 Redes IEEE 802.11 9 IEEE 802.11 e Wi-Fi 10 IEEE 802.11 – arquitetura e modos de operação 10 Modos de operação: ad hoc 10 Modos de operação: infraestruturado 11 Componentes em redes ad hoc 12 Componentes em redes infraestruturadas 12 Arquitetura: Basic Service Set 12 iii

Arquitetura: Independent BSS 13 Arquitetura: infrastructure BSS 13 Arquitetura: Extended Service Set 14 Identificadores 14 Fluxo de dados em um ESS 14 SSID 15 Sistemas de distribuição 15 Conectando-se a uma rede sem fio 16 Varredura Passiva e Ativa 16 Beacons 17 Recebendo beacons 17 Varredura Passiva 18 Múltiplos APs e ESSIDs 18 Varredura Ativa 19 Estados de uma estação 19 Autenticação 20 Associação 20 Troca de mensagens para associação 20 Depois da associação 21 Reassociação 21 Desassociação e Desautenticação 22 Hand over 22 IEEE 802.11 – Camadas PHY e MAC 22 Camada física (PHY) 22 Canais na faixa de 2,4 GHz 23 Canais na faixa de 5GHz 24 Taxas do IEEE 802.11 24 Camada MAC 25 CSMA/CA 26 O backoff exponencial 26 O quadro 802.11 27 Endereços MAC 28 Endereço de destino 28 Vazão efetiva das redes Wi-Fi 29 iv

Segurança em redes IEEE 802.11 30 O problema da segurança 30 Problemas típicos das redes sem fio 30 Padrões de segurança no Wi-Fi 31 WEP 32 WEP: cifragem 32 WEP: integridade 33 Problemas do WEP 33 WPA 1 34 WPA 1: TKIP 34 WPA 2 35 WPA: Personal versus Enterprise 35 WPA Enterprise: esquema 36 IEEE 802.1X e EAP 36 Robust Security Network (RSN) 37 Recomendações de segurança 37 Requisitos eduroam 38 Atividade Prática 1 – Configurar AP para autenticar em servidor RADIUS 38 Cadastrando o AP no servidor RADIUS 38 Configurando roteador com DD-WRT 39 Configurando o roteador sem fio Linksys WRT54G  41

3. Métodos de autenticação Introdução 43 Autenticação em redes 802.11 43 IEEE 802.11i 44 IEEE 802.1X 45 Arquitetura IEEE 802.1X 45 O protocolo EAP 46 Transação EAP 47 Exemplo de transação EAP 48 Métodos EAP 49 TLS (Transport Layer Security) 50 TTLS e PEAP 50 v

Métodos de autenticação interna 51 Password Authentication Protocol (PAP) 51 Microsoft Challenge-Handshake Authentication Protocol (MSCHAP) 52 PAP e MSCHAPv2 – disponibilidade atual 52 Outros métodos (menos usados) 53 Métodos EAP e eduroam 53 Atividade Prática 2 – Configurar clientes com diferentes métodos de autenticação 54 Configuração de dispositivos para TTLS/PAP 54 Configurações para Android 54 Configurações para Windows 55 Configurações para Linux (Ubuntu) 57 Configuração de dispositivos para PEAP/MSCHAPv2 58 Configurações para Android 58 Configurações para Windows XP 59

4. RADIUS – Visão geral e conceitos fundamentais Introdução 63 Cliente RADIUS 64 Servidor RADIUS 64 Serviços oferecidos pelo RADIUS 64 RADIUS e EAP 65 RADIUS e IEEE 802.11 65 NAS 65 Suplicante 66 RADIUS e eduroam 66 O protocolo RADIUS 66 Formato da mensagem RADIUS 67 Tipos de mensagens RADIUS 67 Outros campos das mensagens RADIUS 68 Alguns atributos transportados nas mensagens RADIUS 68 Exemplo (parte 1) 69 Exemplo (parte 2) 69 Exemplo (parte 3): Cliente autenticado e pacote de Access-Accept retornado ao NAS 70 Comandos do FreeRADIUS 70

vi

Atividade Prática 3 – Instalação e configuração de um servidor RADIUS  71 Instalando o RADIUS 71 Configurando o RADIUS sem federação 71 Configurando o ponto de acesso para autenticar em servidor RADIUS  77

5. LDAP – Visão geral e conceitos fundamentais Introdução 79 Surgimento do LDAP 80 Versões do LDAP 80 Operação do LDAP 81 Cliente e Servidor LDAP 81 Protocolo LDAP  82 Organização e estruturas do LDAP 82 Modelos LDAP 83 Modelo de Informação do LDAP 83 Tipos de classe de objeto 83 Directory Information Tree 84 Descrição da árvore e das entradas – LDIF 84 Esquemas LDAP 85 Esquema brEduPerson 85 Classes de objetos no esquema brEduPerson 86 OpenLDAP 86 OpenLDAP: iniciando e parando o servidor 87 Atividade Prática 4 – Instalação e configuração de um servidor LDAP 87

6. Roaming no eduroam: conceitos e funcionamento Introdução 97 Estrutura hierárquica 98 Realms (domínio) 98 Infraestrutura do provedor de acesso 99 Processo de autenticação local 99 Processo de Autenticação Remota 100 Servidor de encaminhamento – proxy RADIUS 100 Atividade Prática 5 – Configuração de proxy para a federação (roaming) 101 vii

Configurando o proxy da federação 104 Teste de roaming 106

7. RadSec: Segurança na comunicação RADIUS Introdução 107 Deficiências na segurança do RADIUS 108 Vulnerabilidades do MD5 108 Vantagens do RadSec 109 Compatibilidade RADIUS UDP vs RadSec 109 Autenticação com RadSec 110 Implementações 112 O radsecproxy 112 Comandos do radsecproxy  113 Atividade Prática 6 – Configuração do proxy com RadSec 113 Instalação do RadSec em cada instituição 114

8. RADIUS Accounting: conceitos e finalidade Introdução 129 RADIUS Accounting 130 Accounting e RadSec 130 Mensagens de accounting 131 Atributos das mensagens de accounting 131 Atributos Acct-Status-Type 132 Troca de mensagens 133 Accounting e roaming 133 Atividade Prática 7 – Configuração do accounting e banco de dados PostgreSQL 134 Instalação e configuração do suporte ao accounting 134 Instalação do PostgreSQL 135 Configurando FreeRADIUS para accounting 135 Uso do phppgadmin para visualizar os dados coletados 137 Outras ferramentas de visualização 140 Considerações finais 141

Bibliografia  143 viii

Escola Superior de Redes A Escola Superior de Redes (ESR) é a unidade da Rede Nacional de Ensino e Pesquisa (RNP) responsável pela disseminação do conhecimento em Tecnologias da Informação e Comunicação (TIC). A ESR nasce com a proposta de ser a formadora e disseminadora de competências em TIC para o corpo técnico-administrativo das universidades federais, escolas técnicas e unidades federais de pesquisa. Sua missão fundamental é realizar a capacitação técnica do corpo funcional das organizações usuárias da RNP, para o exercício de competências aplicáveis ao uso eficaz e eficiente das TIC. A ESR oferece dezenas de cursos distribuídos nas áreas temáticas: Administração e Projeto de Redes, Administração de Sistemas, Segurança, Mídias de Suporte à Colaboração Digital e Governança de TI. A ESR também participa de diversos projetos de interesse público, como a elaboração e execução de planos de capacitação para formação de multiplicadores para projetos educacionais como: formação no uso da conferência web para a Universidade Aberta do Brasil (UAB), formação do suporte técnico de laboratórios do Proinfo e criação de um conjunto de cartilhas sobre redes sem fio para o programa Um Computador por Aluno (UCA).

A metodologia da ESR A filosofia pedagógica e a metodologia que orientam os cursos da ESR são baseadas na aprendizagem como construção do conhecimento por meio da resolução de problemas típicos da realidade do profissional em formação. Os resultados obtidos nos cursos de natureza teórico-prática são otimizados, pois o instrutor, auxiliado pelo material didático, atua não apenas como expositor de conceitos e informações, mas principalmente como orientador do aluno na execução de atividades contextualizadas nas situações do cotidiano profissional. A aprendizagem é entendida como a resposta do aluno ao desafio de situações-problema semelhantes às encontradas na prática profissional, que são superadas por meio de análise, síntese, julgamento, pensamento crítico e construção de hipóteses para a resolução do problema, em abordagem orientada ao desenvolvimento de competências. Dessa forma, o instrutor tem participação ativa e dialógica como orientador do aluno para as atividades em laboratório. Até mesmo a apresentação da teoria no início da sessão de aprendizagem não é considerada uma simples exposição de conceitos e informações. O instrutor busca incentivar a participação dos alunos continuamente .

ix

As sessões de aprendizagem onde se dão a apresentação dos conteúdos e a realização das atividades práticas têm formato presencial e essencialmente prático, utilizando técnicas de estudo dirigido individual, trabalho em equipe e práticas orientadas para o contexto de atuação do futuro especialista que se pretende formar. As sessões de aprendizagem desenvolvem-se em três etapas, com predominância de tempo para as atividades práticas, conforme descrição a seguir: Primeira etapa: apresentação da teoria e esclarecimento de dúvidas (de 60 a 90 minutos). O instrutor apresenta, de maneira sintética, os conceitos teóricos correspondentes ao tema da sessão de aprendizagem, com auxílio de slides em formato PowerPoint. O instrutor levanta questões sobre o conteúdo dos slides em vez de apenas apresentá-los, convidando a turma à reflexão e participação. Isso evita que as apresentações sejam monótonas e que o aluno se coloque em posição de passividade, o que reduziria a aprendizagem. Segunda etapa: atividades práticas de aprendizagem (de 120 a 150 minutos). Esta etapa é a essência dos cursos da ESR. A maioria das atividades dos cursos é assíncrona 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 dúvidas e oferecer explicações complementares. Terceira etapa: discussão das atividades realizadas (30 minutos). O instrutor comenta cada atividade, apresentando uma das soluções possíveis para resolvê-la, devendo ater-se àquelas que geram maior dificuldade e polêmica. Os alunos são convidados a comentar as soluções encontradas e o instrutor retoma tópicos que tenham gerado dúvidas, estimulando a participação dos alunos. O instrutor sempre estimula os alunos a encontrarem soluções alternativas às sugeridas por ele e pelos colegas e, caso existam, a comentá-las.

Sobre o curso O curso aborda todos os conhecimentos necessários para a construção do ambiente de autenticação seguro e distribuído oferecido pelo eduroam. O texto está estruturado em oito capítulos. Após a introdução, que oferece uma visão geral do serviço eduroam, são estudadas as redes sem fio padrão IEEE 802.11, seus mecanismos de segurança e métodos de autenticação. O padrão RADIUS, utilizado para implementar o mecanismo de autenticação distribuído, assim como o LDAP, recomendado para o armazenamento das credenciais dos usuários, são abordados na sequência. Os últimos capítulos são dedicados a tópicos especiais sobre o serviço RADIUS, como as configurações que permitem a mobilidade (roaming) de usuários entre instituições, o RadSec, que oferece comunicação segura entre servidores RADIUS, e a funcionalidade de accounting, que permite o registro das estatísticas de autenticação e uso da rede. Para realização do curso em 24 horas, divididas em 6 sessões de 4 horas cada, é recomendada a seguinte distribuição: Sessão 1: Capítulos 1 e 2 executando a Atividade Prática 1 no fim da sessão; Sessão 2: Capítulo 3 executando a Atividade Prática 2 no fim da sessão; Sessão 3: Capítulo 4 executando a Atividade Prática 3 no fim da sessão; Sessão 4: Capítulo 5 executando a Atividade Prática 4 no fim da sessão; Sessão 5: Capítulo 6 executando a Atividade Prática 5 no fim da sessão; Sessão 6: Capítulos 7 e 8 executando a Atividade Prática 6 (após o capítulo 7) e a Atividade Prática 7 no fim da sessão.

x

A quem se destina Analistas, gerentes de redes e gerentes de TI de instituições que tenham interesse em oferecer o serviço eduroam. É ainda destinado a profissionais que desejem adquirir conhecimentos sobre infraestruturas distribuídas de autenticação e acesso seguro em redes sem fio.

Convenções utilizadas neste livro As seguintes convenções tipográficas são usadas neste livro: Itálico Indica nomes de arquivos e referências bibliográficas relacionadas ao longo do texto.

Largura constante Indica comandos e suas opções, variáveis e atributos, conteúdo de arquivos e resultado da saída de comandos. Comandos que serão digitados pelo usuário são grifados em negrito e possuem o prefixo do ambiente em uso (no Linux é normalmente # ou $, enquanto no Windows é C:\).

Conteúdo de slide Indica o conteúdo dos slides referentes ao curso apresentados em sala de aula.

Símbolo Indica referência complementar disponível em site ou página na internet.

Símbolo Indica um documento como referência complementar.

Símbolo Indica um vídeo como referência complementar.

Símbolo Indica um arquivo de aúdio como referência complementar.

Símbolo Indica um aviso ou precaução a ser considerada.

Símbolo Indica questionamentos que estimulam a reflexão ou apresenta conteúdo de apoio ao entendimento do tema em questão.

Símbolo Indica notas e informações complementares como dicas, sugestões de leitura adicional ou mesmo uma observação.

Permissões de uso Todos os direitos reservados à RNP. Agradecemos sempre citar esta fonte quando incluir parte deste livro em outra obra. Exemplo de citação: SAADE, Débora Christina Muchaluat; CARRANO, Ricardo Campanha; SILVA, Edelberto Franco. Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada. Rio de Janeiro: Escola Superior de Redes, RNP, 2013. xi

Comentários e perguntas Para enviar comentários e perguntas sobre esta publicação: Escola Superior de Redes RNP Endereço: Av. Lauro Müller 116 sala 1103 – Botafogo Rio de Janeiro – RJ – 22290-906 E-mail: [email protected]

Sobre os autores Débora Christina Muchaluat Saade é professora associada do Departamento de Ciência da Computação da Universidade Federal Fluminense (UFF). É engenheira de computação formada pela PUC-Rio e possui mestrado e doutorado em informática pela mesma universidade. É bolsista de produtividade em Desenvolvimento Tecnológico e Extensão Inovadora pelo CNPq e foi Jovem Cientista do Estado do Rio de Janeiro pela Faperj. Suas áreas de pesquisa são redes de computadores, redes sem fio, sistemas multimídia e hipermídia, 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 instituições, implantando o serviço piloto eduroam no Brasil. Ricardo Campanha Carrano é engenheiro de telecomunicações formado em 1995 pela Universidade Federal Fluminense. Em 2008, obteve o título de Mestre em Engenharia de Telecomunicações pela mesma instituição e atualmente cursa o doutorado em Computação, também na UFF, onde atua como Professor do Departamento de Engenharia de Telecomunicações. Foi empresário e participou da implantação de provedores de acesso no início 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 Informação pela Faculdade Metodista Granbery em 2006, e obteve o título de Mestre em Computação pela Universidade Federal Fluminense em 2011. Atualmente é Doutorando em Computação pela Universidade Federal Fluminense. Participou de diversos projetos de pesquisa, possuindo experiência na área de Ciência da Computação, com ênfase em redes, atuando principalmente nos temas relacionados a redes sem fio, Internet do Futuro e segurança. Luiz Claudio Schara Magalhães é graduado em Engenharia Elétrica com ênfase em Sistemas pela PUC-Rio em 1989, Mestre em Ciência de Computação pela PUC-Rio em 1993 e Doutor em Ciência da Computação pela University of Illinois at Urbana-Champaign em 2002. Vem atuando como professor da Universidade Federal Fluminense desde 1994 no Departamento de Engenharia de Telecomunicações. Coordenou e participou de diversos projetos de pesquisa financiados pela RNP, FAPERJ, CNPq e FINEP, incluindo o projeto piloto Eduroam-br. Seus maiores interesses são redes sem fio, computação móvel e Internet do Futuro. Renato Duarte é formado em Ciência da Computação pela UniCarioca e trabalha há treze anos na área. Atualmente é responsável pela área acadêmica de Mídias de Suporte à Colaboração Digital e coordena a equipe de analistas das unidades da Escola Superior de Redes da Rede Nacional de Ensino e Pesquisa (ESR-RNP). É responsável pela infraestrutura de TI de apoio à coordenação da ESR, e pelo preparo e validação dos laboratórios para execução das atividades práticas dos cursos da ESR.

xii

1 Compreender os principais conceitos envolvidos no serviço eduroam, desenvolvendo uma visão geral do serviço e de suas tecnologias-chave.

Serviço eduroam, autenticação e roaming, Federação Acadêmica.

conceitos

Introdução O education roaming (eduroam) é uma iniciativa da Trans-European Research and Education Networking Association (Terena) para oferecer serviço de acesso sem fio seguro desenvolvido para a comunidade internacional de educação e pesquisa. O serviço eduroam permite que estudantes, pesquisadores e a equipe de instituições participantes obtenham conectividade à internet, através de conexão sem fio segura, dentro de seus campi e quando visitam as instituições que participam da federação 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 provisória “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 própria política para a criação de logins, e atribuem a essa conta a senha “senha1234”, também de acordo com sua política 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 Grosso do Sul (UFMS), receberá um terceiro par de login e senha: “silvaj” (o professor pediu o login “jsilva”, mas este já era utilizado por outro usuário) e senha “123senha”. Passados mais alguns meses, o professor retorna à UFRJ e, ao pedir um acesso, é lembrado de que já possui uma conta naquela instituição. Mas será “jsilva”, “jose.silva” ou “silvaj”? E a senha, qual seria? Esse exemplo expõe ao menos duas deficiências graves nesse esquema improvisado de autenticação. A primeira é a dificuldade que as instituições visitadas terão em criar e, eventualmente, em remover essas contas. Qual o processo para esse tipo de solicitação? Por quanto tempo essas contas devem permanecer válidas? Quem é o responsável, caso haja abusos? Em segundo lugar, vem a óbvia dificuldade do visitante. Ele não pode esperar que se criem os mesmos logins e senhas em todas as instituições visitadas. Como memorizar todas elas?

Capítulo 1 - Visão geral do eduroam

objetivos

Visão geral do eduroam

1

O eduroam oferece uma resposta para esses problemas. As credenciais usadas pelo professor José Silva, de nosso exemplo, serão as criadas em sua instituição de origem (a Unicamp, no caso). Não haverá necessidade de criação de contas em nenhuma das instituições visitadas para acesso à rede sem fio.

1

2

jsilva senha123

Por favor, gostaria de acessar a rede?

jose.silva senha1234

Anote o login e a senha!

3

Anote o login e a senha!

4

Por favor, gostaria de acessar a rede?

silvaj 123senha

jsilva senha123 jose.silva senha1234 silvaj 123senha

Anote o login e a senha!

Conforme se pode ver no mapa da Figura 1.2, o eduroam está presente em diversas

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

instituições ao redor do mundo, organizadas em três confederações: uma na Europa, outra

2

Por favor, gostaria de acessar a rede?

na América do Norte e a terceira na Ásia/Oceania. A América Latina iniciou sua inserção a partir do projeto piloto Eduroam-br, apoiado pela RNP em parceria com a Cooperação Latino-Americana de Redes Avançadas (RedClara). Em 2012, Brasil e Peru foram autorizados a atuar como roaming operators, oferecendo o serviço eduroam na América Latina.

?

Por favor, gostaria de acessar a rede?

?

?

Você já tem conta aqui, certo?

Figura 1.1 Problema de gestão a partir de bases completamente isoladas.

8

1224

16 NORTH AMERICA

29

ASIA

EUROPE

67 Atlantic Ocean

763 3337

48 AFRICA

Pacific Ocean

SOUTH AMERICA

Indian Ocean

AUSTRALIA 393

Figura 1.2 Demonstração dos continentes inseridos no projeto eduroam após o ingresso da América Latina (situação em dezembro de 2012) [eduroam, 2012].

O projeto eduroam-br O projeto eduroam-br iniciou-se em 2011 a partir da motivação de integração das universidades brasileiras ao serviço eduroam mundial. A RNP, junto com as universidades Federal Fluminense, Federal do Rio de Janeiro e Federal de Mato Grosso do Sul deu início ao piloto que contou posteriormente com mais sete voluntárias (UFSC, Unicamp, UFRGS, UFES, UFMG, UFPA e PUCRS). O projeto piloto Eduroam-br foi concluído em julho de 2012, tornando-se um serviço no portfólio da RNP.

Tecnologias utilizadas no eduroam O serviço eduroam é uma arquitetura distribuída de servidores de autenticação, onde o pedido de autenticação de um usuário é sempre tratado em sua instituição de origem. Quando um usuário está em sua própria instituição, o pedido de autenticação desse usuário para acesso à rede de sua instituição é tratado pelo servidor de autenticação local. Quando um usuário estiver visitando uma instituição parceira, o pedido de autenticação desse usuário para acesso à rede da instituição visitada é enviado ao servidor de autenticação de sua instituição de origem para que suas credenciais sejam verificadas. O serviço eduroam se baseia na utilização do padrão internacional Remote Authentication Dial In User Service (RADIUS), publicado pelo Internet Engineering Task Force (IETF). A infra-

Saiba mais

l

Para saber mais sobre a CAFe, visite o site da RNP: http://www.rnp. br/servicos/cafe.html

sem fio IEEE 802.11 e se apoia no padrão IEEE 802.1X e no padrão IEEE 802.11i para prover mecanismos de acesso seguro. As informações utilizadas para autenticação de usuários, preferencialmente, devem ser armazenadas em diretórios utilizando bases LDAP. Além disso, cada instituição deve garantir a credibilidade das credenciais de seus usuários. Sendo assim, o serviço eduroam pressupõe uma relação de confiança entre as instituições participantes, seguindo o conceito de federação. Por isso, para que uma instituição brasileira possa oferecer o serviço eduroam, esta deve ser um provedor de identidade (IdP) da Comunidade Acadêmica Federada (CAFe).

Capítulo 1 - Visão geral do eduroam

estrutura de rede necessária para oferecer o serviço, basicamente, utiliza pontos de acesso

3

Figura 1.3 Logotipo da Comunidade Acadêmica Federada.

RADIUS O Remote Authentication Dial In User Service (RADIUS) é um padrão IETF, especificado na RFC 2865, que oferece serviço de Autenticação, Autorização e Auditoria (AAA) consolidado no mercado como uma solução robusta. O protocolo RADIUS opera sobre o protocolo de transporte UDP e utiliza, por padrão, a porta 1812. Desenvolvido no início da década 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 métodos mais seguros para controle de acesso às redes sem fio. Servidores RADIUS são responsáveis por:

q

11 Receber solicitações de conexão. 11 Autenticar usuários. 11 Retornar todas as informações de configuração necessárias para o cliente (NAS – Network Access Server) prover conectividade a um usuário. 11 Podem atuar como um cliente proxy de outros servidores de autenticação. O objetivo do processo de autenticação é a garantia de que o emissor de uma mensagem é, de fato, quem ele diz ser. Em geral, a autenticação ocorre entre um cliente e um servidor e pode ser feita através da apresentação 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 solicitações de autenticação até outro servidor para que seja realizada a verificação das credenciais do cliente.

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

IEEE 802.11i

4

A emenda IEEE 802.11i, publicada em 2004, foi desenvolvida justamente para sanar as questões de segurança em redes sem fio 802.11. Uma versão provisória da emenda foi publicada em 2003 com alterações compatíveis com os equipamentos já fabricados, para combater a crescente descrença na tecnologia WiFi. Essa primeira versão do IEEE 802.11i se convencionou chamar WPA1, enquanto WPA2 serve para designar a implementação final do IEEE 802.11i, que requeria mudanças no hardware dos dispositivos. O WPA2 é a implementação completa de segurança para rede local sem fio e é recomendada para o uso corporativo. Um aspecto importante é que ela permite autenticar usuários em vez de máquinas. É preciso reconhecer que os mecanismos de chave pré-compartilhada se tornam inseguros pelo reuso constante e ocasional exposição da chave (em avisos públicos ou pela divulgação boca a boca) e pela necessidade de troca constante, cada vez que um membro da equipe deixa a instituição – um procedimento raramente executado. Por esses motivos, a autenticação de usuários, como prevista no WPA2, é fundamental. Para alcançar esse objetivo, o IEEE 802.11i recomenda o emprego de outra tecnologia pré-existente, o IEEE 802.1X (nesse caso, o X é maiúsculo).

IEEE 802.1X O padrão IEEE 802.1X é um arcabouço (framework) de autenticação para as tecnologias de rede da família IEEE 802. Na verdade, o IEEE 802.1X apenas descreve o encapsulamento de um padrão pré-existente, o Extensible Authentication Protocol (EAP), sobre os padrões 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 padrão IEEE 802.1X que ampliou seu uso para outros tipos de enlace. O EAP não descreve um mecanismo de autenticação. Essa autenticação é realizada por um protocolo de extensão chamado de Método EAP. Os métodos podem ser mais ou menos adaptados às necessidades específicas de uma rede.

Arquitetura IEEE 802.1X a)

Suplicante

RADIUS

EAPOL

Autenticador

Servidor de Autenticação

b) método EAP EAP 802.1X

802.1X

802.1 1

802.1 1

RADIUS

RADIUS

UDP/IP

UDP/IP

802.3

802.3

Na arquitetura IEEE 802.1X, apresentada na Figura 1.4, chama-se de suplicante o dispositivo que busca autenticação. No caso das redes sem fio, o suplicante é o cliente que se associa à rede através de um ponto de acesso (AP – Access Point). O ponto de acesso tem a função de autenticador e seu papel é intermediar o processo, enviando a informação do suplicante a um Servidor de autenticação RADIUS, que consulta a base de dados de usuários. Entre o suplicante e o autenticador, o protocolo usado é o EAP e, entre o autenticador e o servidor de autenticação, é utilizado o protocolo RADIUS.

Comunidade Acadêmica Federada A Comunidade Acadêmica Federada (CAFe) é uma federação de identidade que reúne instituições de ensino e pesquisa brasileiras. Através da CAFe, um usuário mantém todas as suas informações na instituição de origem e pode acessar serviços oferecidos pelas instituições que participam da federação. Como se pode observar, o conceito envolvido na CAFe segue o mesmo do eduroam, uma vez que a CAFe possibilita que cada usuário tenha uma conta única em sua instituição de origem, válida para todos os serviços oferecidos à federação,

Capítulo 1 - Visão geral do eduroam

Figura 1.4 Comunicação entre o suplicante, o autenticador e o servidor de autenticação RADIUS [Gant, 2002].

eliminando a necessidade de múltiplas senhas de acesso e processos de cadastramento. 5

Instituições pertencentes à CAFe podem atuar como provedor de identidade (IdP) e provedor de serviço (ISP), sendo que a RNP, que mantém esse serviço, provê subsídio completo no custo associado ao uso do serviço da CAFe a essas instituições. Além disso, nenhum dos acordos atuais prevê qualquer custo para os provedores de serviço. A relação de confiança entre instituições participantes da federação permite que o usuário se autentique unicamente em sua instituição de origem, que fornece as garantias de autenticidade e credibilidade necessárias às demais instituições. A base de dados LDAP, que armazena as credenciais para acesso ao serviço eduroam no Brasil, é a mesma base LDAP utilizada pela instituição provedora de identidade na federação CAFe.

Funcionamento do eduroam

q

O eduroam utiliza estrutura hierárquica de servidores RADIUS em três níveis: 11 Confederação. 11 Federação (país). 11 Instituição. Maior Nível de Confederação Servidor RADIUS (resiliente)

Maior Nível de Federação Servidor RADIUS .BR

.AR

Nível Institucional Servidores RADIUS inst-1

inst-2

inst-3

inst-4

Na estrutura hierárquica de três níveis utilizada no serviço eduroam (representada na Figura 1.5),

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

o terceiro nível compreende as instituições participantes. Cada instituição é representada

6

por ao menos um servidor RADIUS e sua base de dados LDAP. Já no segundo nível há o ponto central do país (federação), ao qual a instituição é subordinada. Como primeiro nível dessa hierarquia tem-se o servidor da confederação, que é aquele que interliga todos os servidores das federações participantes. Usuários de cada instituição participante do eduroam possuem como identificação seu domínio associado. Assim como no Domain Name System (DNS), os domínios (Fully Qualified Domain Name – FQDN) são formados conforme sua subordinação. Por exemplo, a Universidade Federal Fluminense, que é subordinada ao ponto central do Brasil, representado pelo “.br”, terá como domínio final “@uff.br”.

Figura 1.5 Hierarquia de servidores RADIUS no eduroam.

Autenticação na instituição de origem Servidor da Federação eduroam.br proxy RADIUS

Instituição Visitada

Instituição de Origem

inst1.edu.br Servidor RADIUS

inst2.edu.br Usuário em roaming

Figura 1.6 Exemplo de consulta à base local para usuário em roaming entre instituições.

AP

inst2.edu.br Servidor RADIUS

inst1.edu.br Servidor LDAP

inst2.edu.br Servidor LDAP

No serviço eduroam, o acesso à internet através de uma instituição parceira é denominado roaming e possibilita ao visitante utilizar sua própria credencial para autenticação. Como exemplificado na Figura 1.6, pode-se imaginar um usuário da instituição inst2.edu.br (exemplo: [email protected]) visitando a instituição inst1.edu.br. O pedido de autorização de acesso desse usuário será recebido pelo servidor RADIUS da instituição visitada, que por sua vez, ao verificar que o domínio relacionado ao usuário não corresponde a um domínio local, encaminhará a solicitação ao servidor de nível acima (federação). Uma vez encontrada a instituição de origem do usuário, a requisição é então encaminhada a ela, que realiza a verificação necessária e retorna a resposta pelo caminho contrário.

Figura 1.7 Disposição da hierarquia de servidores latino-americanos e servidores eduroam raiz.

Interconexão com América Latina e Europa

Proxy LATLR CLARA

EDUROAM

Proxys ETLR GEANT

.pe

.pe

inictel-uni.edu.pe

.dk

.br

uni.edu.pe

uff.br

ufrj.br

ufms.br

ufsc.br

unicamp.br

ufrgs.br

Capítulo 1 - Visão geral do eduroam

.nl

7

A infraestrutura de servidores de autenticação eduroam no âmbito nacional se interliga à rede eduroam internacional por meio do servidor RADIUS, que representa a confederação latinoamericana. Esse servidor, por sua vez, possui conexão com os servidores redundantes no nível da confederação eduroam internacional. A Figura 1.7 apresenta esse esquema de interconexão, indicando algumas instituições brasileiras e peruanas que oferecem o serviço eduroam. Como comentado, Brasil e Peru foram os primeiros países da América Latina credenciados

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

como operadores de roaming do eduroam.

8

2 Conhecer as principais características do padrão IEEE 802.11, assim como os riscos associados a seu uso e suas demandas de segurança. Compreender a necessidade de um sistema de autenticação robusto.

conceitos

Redes sem fio IEEE 802.11. Arquitetura de uma rede IEEE 802.11. Camada física (PHY) e camada MAC. Esquemas de segurança WEP e WPA (1 e 2, Personal e Enterprise).

Introdução Redes locais sem fio têm diversos usos, dentre os quais se destaca o acesso à internet. Esse uso bastante comum é resultado da proliferação de dispositivos móveis, como laptops, tablets e smartphones, nos quais os modelos que possuem interfaces de rede sem fio são cada vez mais comuns. Esses dispositivos móveis e portáteis trazem conforto e flexibilidade aos usuários. Redes sem fio também podem ser usadas por computadores fixos, em locais onde o cabeamento pode ser difícil ou impossível de ser feito, como prédios históricos, e para instalações provisórias, que não compensam o custo de fazer uma instalação cabeada ou onde fios expostos (pela falta de tubulação adequada) podem atrapalhar a circulação das pessoas.

Redes IEEE 802.11 11 O IEEE 802.11 é o padrão de redes locais sem fio.

q

22 Ele foi pensado como uma extensão do padrão de redes com fio Ethernet (IEEE 802.3). 11 O padrão IEEE 802.11 evolui constantemente, através da criação de emendas. 22 A emendas “a”, “g” e “n” determinam camadas físicas. 22 A emenda “i” trouxe mais segurança. O Institute of Electrical and Electronic Engineers (IEEE) é uma organização profissional sem fins lucrativos. Seu objetivo é promover o conhecimento em áreas de engenharia elétrica, computação e telecomunicações. Isso é feito através da publicação de revistas e promoção de congressos. Outra das suas atribuições é o estabelecimento de padrões baseados em consenso. Um padrão recebe um número, como o IEEE 802.11, que é um subpadrão do grupo de redes locais e metropolitanas (802), e especifica uma tecnologia de rede local sem fio.

Capítulo 2 - Redes sem fio IEEE 802.11

objetivos

Redes sem fio IEEE 802.11

9

O IEEE 802.11 tem emendas, como o IEEE 802.11g, IEEE 802.11a e IEEE 802.11n. As emendas complementam o padrão, atendendo a novas demandas, adaptando o padrão a regulamentações nacionais e acrescentando novas tecnologias para implementação da camada física, que determina a técnica de transmissão e modulação do sinal no meio sem fio. Das três emendas citadas (“a”, “g” e “n”), cada uma estabelece um padrão 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 técnicas adicionais para atingir taxas de até 300Mbps em 2.4GHz e 5GHz.

IEEE 802.11 e Wi-Fi 11 Wi-Fi não é o mesmo que IEEE 802.11.

q

11 IEEE 802.11 é um padrão. 11 Wi-Fi é um certificado, dado pela Wi-Fi Alliance, que garante que os produtos com esse certificado falarão entre si. 11 Um produto Wi-Fi não tem de implementar todo o padrão IEEE 802.11, apenas a parte necessária para interoperar. 11 Por isso, podemos dizer que Wi-Fi é um perfil do IEEE 802.11. Apesar de muitas vezes serem usados como sinônimos, Wi-Fi não é o mesmo que IEEE 802.11. O último é um padrão, enquanto o primeiro se refere à certificação da Wi-Fi Alliance, uma cooperativa de indústrias que busca a interoperação de redes sem fio. Todos os produtos com a certificação Wi-Fi podem interoperar. Por outro lado, a certificação Wi-Fi não requer a implementação completa do padrão IEEE 802.11. Apenas o perfil escolhido, e de forma que permita interoperação.

IEEE 802.11 – arquitetura e modos de operação O padrão IEEE 802.11 define dois modos de operação, que resultam em duas

q

arquiteturas distintas:

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

11 Modo infraestruturado:

10

22 Todo o tráfego é intermediado por pontos de acesso (AP). 11 Modo ad hoc: 22 Não 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 propósito diferente. O modo sem infraestrutura, chamado modo ad hoc, serve para troca ocasional de informações, ao passo que o modo infraestruturado serve para estender uma rede com fio. Estudaremos ambos os modos a seguir.

Modos de operação: ad hoc 11 O modo ad hoc serve para interconectar máquinas que estejam próximas para comunicação ocasional. 11 Por exemplo, para trocar arquivos entre os participantes de uma reunião ou para a cooperação entre alunos em uma sala de aula. 11 As máquinas não têm ligação com redes cabeadas, a não ser que seja rodado software de roteamento.

q

Para estabelecer comunicação ocasional entre máquinas 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 múltiplas máquinas. Essas máquinas podem, então, trocar informações usando qualquer aplicação de rede. A pilha de protocolos TCP/IP roda sobre máquinas em uma rede ad hoc da mesma forma que roda sobre Ethernet. Deve ficar claro que uma rede ad hoc é formada por máquinas que conseguem falar entre si diretamente, ou seja, em um único salto, por exemplo, diversos laptops dentro da mesma sala de reunião. A conectividade em múltiplos saltos é possível através da emenda IEEE 802.11s ou do uso de protocolos de roteamento para redes ad hoc, no nível de aplicação (como OLSR ou AODV, entre outros), mas esse cenário está fora do escopo deste livro.

Modos de operação: infraestruturado 11 O modo infraestruturado foi feito para estender uma rede com fio.

q

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 comunicação passa pelo AP. 22 Mesmo aquela entre dois nós sem fio que poderiam formar uma rede ad hoc entre si. O modo ad hoc não requer nenhum outro hardware além dos computadores com placas de rede sem fio. Já o modo infraestruturado requer um equipamento para fazer a tradução 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 nível 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 comunicação 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 nós têm interfaces de rede sem fio e estão próximos o suficiente para permitir comunicação entre eles), ainda assim o primeiro enviaria os pacotes para o AP e este os enviaria para a outra máquina 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 usuários domésticos, normalmente implementam outras funções, além de servirem de interface entre a rede com fio e a rede sem fio. Eles incluem um switch, para permitir a ligação de máquinas com fio (pontos de acesso puros só têm uma interface de rede), e separam uma porta desse switch para ser a ligação “externa” da rede (normalmente denominada porta WAN). Essa porta estaria ligada normaldispositivo incorpora um cable modem ou modem ADSL.

Capítulo 2 - Redes sem fio IEEE 802.11

mente ao modem ADLS ou modem para TV a cabo (cable modem). Muitas vezes o próprio

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 próximos o suficiente para garantir sua comunicação direta. Nesse tipo de configuração, as interfaces de rede das estações falam entre si em vez de com o ponto de acesso.

Componentes em redes infraestruturadas Rede Cabeada Área de cobertura

Área de cobertura Ponto de Acesso Sem fio

Ponto de Acesso Sem fio Adaptador Sem Fio (USB)

Adaptador Sem Fio (Cartão)

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

Adaptador Sem Fio (PCI)

12

Antena extensora de cobertura

Nas redes com infraestrutura, são necessários, além 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. Além disso, são necessários cabeamento e elementos de interconexão (como switches e roteadores) para ligar a rede à internet (e possivelmente interligar vários pontos de acesso).

Arquitetura: Basic Service Set Uma rede 802.11 é composta de um ou mais conjuntos de estações que se comunicam. Um conjunto de estações que se comunica é definido como um Basic Service Set (BSS). Uma estação (nó da rede sem fio) é chamada de STA (station).

Figura 2.2 Exemplo de ligação entre duas redes sem fio por meio cabeado entre os pontos de acesso.

Arquitetura: Independent BSS

Figura 2.3 Exemplo de uma rede ad hoc, onde os nós se comunicam diretamente.

Um BSS independente (Independent Basic Service Set – IBSS) é um conjunto de estações que consegue se comunicar entre si. Ele é também chamado de ad hoc BSS ou rede ad hoc.

Arquitetura: infrastructure BSS Área de cobertura Ponto de Acesso Sem fio

Adaptador Sem Fio (Cartão)

Figura 2.4 Exemplo de uma rede sem fio infraestruturada, com a presença de um ponto de acesso.

Uma rede infraestruturada foi definida como aquela que contém um ponto de acesso. Toda comunicação passa pelo ponto de acesso e, se duas estações do mesmo BSS querem falar uma com a outra, o quadro será transmitido da estação origem para o ponto de acesso, e deste para a estação destino. Apesar de diminuir a capacidade disponível na rede sem fio, preocupar se outras estão ou não dentro de sua área de cobertura, basta estar na área de cobertura do ponto de acesso. Dessa forma, se uma estação com fio deseja enviar um pacote para uma estação na rede sem fio, ela enviará o pacote para o ponto de acesso, que reenviará o pacote para a estação sem fio de destino. Se uma estação sem fio quer enviar um pacote para outra estação sem fio, em outro BSS, ela enviará para seu próprio ponto de acesso (ao qual está associada), que reenviará o quadro para o ponto de acesso associado à estação de destino, que reenviará o quadro para a estação sem fio de destino. Todas essas tarefas requerem que as estações se registrem com os APs. Isso é chamado de uma associação e tem algumas outras atribuições, como auxiliar a segurança da rede.

Capítulo 2 - Redes sem fio IEEE 802.11

isso torna a sua implementação muito mais simples, já que estações não precisam se

A forma de associação vai ser vista posteriormente, mas requer a troca de tráfego de controle entre o AP e a estação. 13

Arquitetura: Extended Service Set Rede Cabeada Área de cobertura

Área de cobertura Ponto de Acesso Sem fio

Ponto de Acesso Sem fio Adaptador Sem Fio (USB)

Adaptador Sem Fio (Cartão) Adaptador Sem Fio (PCI)

Antena extensora de cobertura

Um único BSS pode não ser suficiente para cobrir uma área extensa ou pode ser necessário colocar mais APs para servir um número maior de usuários. Nesse caso, é necessário interligar os BSSs para que estações 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 distribuição (Distribution System – DS). Um nome, chamado de ESSID (identificador de ESS), é usado para identificar um ESS. Todos os BSSs pertencentes ao mesmo ESS têm o mesmo ESSID. A ideia é que cada AP que pertença ao mesmo ESS funcione como um switch numa rede que tenha vários switches interligados. Um switch aprende quais endereços MAC estão atrás de cada porta e envia o quadro para o Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

switch certo dependendo do MAC. Da mesma forma, um AP sabe todos os MACs das estações que o estão usando para comunicação e os publica. Isso também permite mobilidade entre APs de um mesmo ESS.

Identificadores Enquanto o ESSID é um nome associado a uma rede, o BSSID é um endereço, normalmente o endereço MAC do ponto de acesso que define o BSS. Para redes ad hoc, é criado um número aleatório de 46 bits (IBSSID). O BSSID formado só de bits 1 é reservado para quadros de controle que são usados para busca de pontos de acesso para associação. O ESSID será usado para associações (definindo a rede), enquanto o BSSID será usado para o encaminhamento dos quadros enquanto eles vêm de e vão para os pontos de acesso.

Fluxo de dados em um ESS Uma das vantagens do padrão IEEE 802.11 é a possibilidade de deslocamento entre diferentes APs, sem perder conexão de rede enquanto estiver se movimentando por eles. O padrão permite agrupar vários BSSs dentro de um ESS. Isso significa que o ESS consiste em um ou vários BSSs que compartilham o mesmo Identificador de Serviço Básico (SSID). Estações que farão parte do mesmo ESS podem se comunicar com outras estações do grupo, mesmo estando em BSS distintas.

14

Figura 2.5 Exemplo de ligação/ extensão de duas redes sem fio.

AP1

BSS 1 BSS 3

AP2

BSS 2

BSS 4

AP3

Figura 2.6 Exemplo de BSSs distintos com mesmo SSID, formando um ESS.

AP4

Na Figura 2.6, quatro BSSs permitem a mobilidade de estações de forma transparente entre células de APs distintos.

SSID O Identificador de Serviço Básico (SSID) é utilizado para o controle dos APs com os quais as estações desejam se associar. A estação não deve tentar uma associação com o AP, caso ela não tenha o mesmo SSID configurado para iniciar tal mecanismo. 11 O SSID serve para identificar a rede que um cliente está usando.

q

11 No ponto de acesso, o SSID vem pré-configurado com um nome padrão de fábrica: 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 segurança de uma rede. Como o SSID tem de ser conhecido para que uma estação entre na rede, se o SSID não for divulgado, não seria possível entrar na rede. O problema é que é trivial descobrir o SSID, ouvindo (sniffing) o tráfego da rede. Então, a ocultação do SSID não deve ser vista como segurança. A função do SSID não é a de prover segurança, mas a de permitir o convívio de diferentes redes na mesma área. Estações e pontos de acesso ignoram quadros que têm um SSID diferente do seu, permitindo o compartilhamento do canal.

Um sistema de distribuição (Distribution System – DS) é uma rede de nível de enlace

q

que interliga os APs (BSSs) de um ESS. Se as redes sem fio forem pensadas como uma extensão das redes com fio (no modo infraestruturado), é 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, não se pode esperar que um ESS consiga se comunicar através de um roteador. A interligação entre APs (que definem os BSSs) que formam um ESS tem que ser no nível de enlace, isto é, usando apenas elementos como hubs e switches.

Capítulo 2 - Redes sem fio IEEE 802.11

Sistemas de distribuição

15

Um sistema de distribuição (Distribution System – DS) é uma rede que interliga os múltiplos APs de um ESS. Na Figura 2.6, um sistema de distribuição interliga os quatro APs. Existem também os sistemas de distribuição sem fio (WDS, do inglês Wireless Distribution System), que usam as próprias interfaces sem fio dos APs, mas esse mecanismo não é padronizado e apresenta problemas de desempenho.

Conectando-se a uma rede sem fio O processo de criar uma conexão virtual entre um computador (estação) e a rede

q

(através de um ponto de acesso) tem vários passos: 11 Varredura: encontrar os pontos de acesso (scan). 11 Seleção: escolher o ponto de acesso desejado. 11 Autenticação: identificar-se à rede. 11 Associação: associar-se ao ponto de acesso. Em uma rede com fio, o processo de conexão é material, isto é, é feita uma conexão física, usando um cabo entre o computador e o elemento ativo de rede. O elemento ativo mais comum é um switch. O cabo normalmente não é um único segmento, mas um conjunto de segmentos, dada a prevalência do cabeamento estruturado. Numa rede sem fio, obviamente isso é impossível, dada a ausência de cabos. O método de fazer uma conexão virtual entre o computador e o elemento ativo (o ponto de acesso) é chamado de associação. Para haver uma associação, o computador tem de descobrir quais pontos de acesso estão disponíveis, já que pode não haver nenhum indício físico (isto é, os pontos de acesso podem não estar no local ou não estar visíveis). O processo de descobrir os pontos de acesso é chamado de varredura e será explicado a seguir. Uma vez descobertos os pontos de acesso disponíveis, a estação escolhe um deles para se associar. A forma como essa seleção é feita não faz parte do padrão, ficando a cargo de cada fabricante. Uma forma usual é selecionar o ponto de acesso cujos beacons (quadros perió-

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

dicos enviados pelo AP) são recebidos com a maior potência. A próxima fase se inicia com a troca de quadros de autenticação. Como veremos, apesar do nome, esses quadros não proveem um mecanismo realmente confiável de autenticação. Por isso, uma etapa adicional de autenticação ocorrerá após o término da associação. Esse processo será estudado em detalhes adiante. Como não existe segurança física na rede sem fio, em contraste com uma rede com fio onde as tomadas de rede estão dentro das instalações físicas, mais um passo é necessário antes de permitir que a conexão virtual seja usada para trafegar dados para além do ponto de acesso. Esse passo é a autenticação, onde a estação vai se identificar como elegível para usar a rede.

Varredura Passiva e Ativa 11 O processo de identificação da existência 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 específica (usando um determinado Basic Service Set ID – BSSID) ou para qualquer rede (BSSID = Broadcast).

16

q

O processo de encontrar quais pontos de acesso estão disponíveis é chamado de varredura, porque a estação muda seu canal para descobrir pontos de acesso em todos os canais, varrendo a faixa de frequência destinada ao IEEE 802.11. A varredura é ativa se a estação envia um quadro especial (probe request) para identificar a existência de redes nas proximidades do usuário. Ou passiva, se a estação apenas escuta quadros especiais enviados pelos pontos de acesso (beacons). A varredura também pode ser realizada para uma rede específica (usando um determinado Basic Service Set ID – BSSID) ou para qualquer rede (BSSID = Broadcast).

Beacons 11 Quadros de sinalização disseminados pelo AP (em broadcast) a intervalos regulares.

q

11 Fazem o anúncio da existência do AP na rede. 11 São mensagens curtas. 11 O intervalo de transmissão é ajustável (o default é um quadro a cada 100 ms). Beacons são quadros curtos enviados periodicamente pelos APs para avisar de sua presença e passar algumas informações necessárias para as estações que podem querer se associar a eles. O beacon carrega, entre outras informações, o nome (SSID) da rede e qual o método de segurança (WEP, WPA) usado pela rede ou se a rede é aberta.

Recebendo beacons

AP1

EM (Estação Móvel)

Figura 2.7 Envio de beacons a todas as estações móveis em seu raio de alcance.

Envio de Beacons

A Figura 2.7 mostra várias estações móveis e dois APs com suas respectivas áreas de cobertura. Os APs disseminam beacons na área de cobertura, contendo mensagens de tempo de sincronização, serviço da camada física (quais taxas de transmissão podem ser usadas) e valor do SSID, entre outras.

Capítulo 2 - Redes sem fio IEEE 802.11

AP2

17

Caso exista interseção das áreas de cobertura, uma estação pode receber vários beacons. A Figura 2.7 ilustra essa situação. A estação em destaque recebe beacons de dois pontos de acesso. APs e estações podem coexistir na mesma área e usando a mesma frequência, 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 próximos sejam colocados em canais ortogonais (não interferentes). Como o processo de varredura passa por todas as frequências, a estação será capaz de descobrir os pontos de acesso independente do canal em que operam.

Varredura Passiva

q

11 A estação sintoniza um canal e espera por quadros de beacon. 11 Como os quadros contêm informações do ponto de acesso, a estação pode criar uma lista de pontos de acesso. 11 O sistema é eficiente em relação à energia por não exigir a transmissão de quadros pela estação. A varredura passiva refere-se ao processo de procurar por beacons em cada canal. Esses beacons são enviados pelos APs ou estações (no caso de redes ad hoc), para que estações

obtenham informações sobre as redes disponíveis (como o valor do SSID da rede). A estação fazendo a varredura tenta, então, se associar com o BSS utilizando o SSID e outras informações encontradas.

Múltiplos APs e ESSIDs

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

AP1

18

EM descobre: BSS1, AP1 BSS2, AP2 BSS3, AP3

EM (Estação Móvel)

AP2

AP3

AP4

Envio de Beacons

Figura 2.8 Estação móvel recebe beacons de todos os APs que o cobrem.

A Figura 2.8 mostra uma estação móvel (Estação Móvel – EM) e quatro APs. A estação consegue ouvir beacons vindo dos APs que têm a EM presente na sua área de cobertura. Nesse exemplo, a EM recebe notificações de AP1, AP2 e AP3. Como dissemos, a escolha de qual o melhor AP não está no padrão. Dependerá, por exemplo, de qual rede o usuário tem direito de acesso no caso de múltiplas redes ou se todos têm o mesmo ESSID, o AP cujo nível de sinal recebido (RSSI) for o maior entre os demais APs. As interfaces com o usuário normalmente mostrarão as múltiplas redes encontradas (e outras informações, como canal, codificação e nível de sinal) e permitirão que o usuário escolha a qual rede ele quer se associar.

Varredura Ativa 11 A estação móvel envia um probe request para cada canal da lista de canais.

q

11 A estação móvel espera por uma resposta do(s) AP(s). 11 A estação móvel processa o probe response. Na varredura ativa, a estação envia um quadro do tipo probe request. Esse mecanismo ativo é utilizado pelas estações clientes para assegurar a presença de uma rede a qual elas desejem se associar. Esse quadro pode conter o valor do SSID requerido pela estação cliente. Se o SSID for vazio, então todos os pontos de acesso que ouvirem o probe request vão responder.

AP1

EM (Estação Móvel)

Probe Request

AP2

AP3

Figura 2.9 Varredura ativa de uma MS em busca de SSID.

A Figura 2.9 mostra uma estação móvel (EM) iniciando a varredura ativa, enviando o quadro for equivalente ao solicitado pela EM durante a varredura ativa enviarão o probe response. Se a requisição contiver um valor nulo para o SSID, todos os pontos de acesso naquele canal responderão com o probe response.

Estados de uma estação Em um dado momento, uma estação pode estar em um dos três estados: 1. Não autenticada e não associada. 2. Autenticada e não associada.

Capítulo 2 - Redes sem fio IEEE 802.11

probe request. Se a requisição tiver um determinado valor de SSID, apenas os APs cujo SSID

3. Autenticada e associada.

19

Para se autenticar, uma estação trocará quadros de autenticação e, para se associar, quadros de associação. Apenas quando associada, uma estação consegue trocar dados com a rede.

Autenticação 11 Os quadros de autenticação (authentication request e response) trocados nessa fase

q

proveem duas opções: 22 Open system: sistema aberto. 22 Chave pré-compartilhada (PSK). 11 Essa fase de autenticação foi tornada obsoleta pelo IEEE 802.11i. Como veremos adiante, existem dois tipos de autenticação distintos no IEEE 802.11, o primeiro – “Sistema Aberto” (onde o campo Authentication Algorithm Number tem o valor 0) não provê nenhuma autenticação 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 autenticação usado pelo eduroam, tornou essa fase de autenticação obsoleta e oferece um mecanismo muito mais efetivo e seguro, que permite a autenticação de usuários. De fato, o esquema de autenticação com chaves pré-compartilhada não é mais recomendado pelo padrão, apesar de ainda estar disponível nos pontos de acesso, sobretudo os de uso doméstico.

Associação 11 Após a autenticação, a estação pode tentar se associar enviando um quadro

q

association request. 11 Após se associar, ela pode utilizar o AP para acessar a rede da qual faz parte. 11 A estação móvel pode se associar somente a uma única BSS. Uma vez que a estação móvel tenha sido devidamente autenticada, pode tentar se associar ao AP. Em outras palavras, a associação refere-se ao estado em que a estação cliente passa

20

Troca de mensagens para associação O AP cria uma entrada para a EM; Envia um ID de associação à EM; O AP tem o MAC da EM.

(1) Association Request

EM (Estação Móvel)

(2) Association Response (inclui o AID) Tráfego

AP Barramento

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

a fazer parte de uma BSS.

Endereço MAC da EM

AID

08:00:45:37:41:7d

Um valor de [1 a 2007)

Figura 2.10 Passo a passo da associação de uma EM a um AP.

A Figura 2.10 mostra os estágios de associação de uma estação móvel junto ao AP: 11 O primeiro passo é enviar uma requisição de associação (Association Request) ao AP. 11 Recebendo essa requisição e a aceitando, o AP cria uma entrada para a estação e envia uma mensagem de anúncio ARP (gratuitous ARP) na rede cabeada com o endereço MAC da estação. Isso a registra nos elementos ativos (switches). Em seguida, envia uma identificação (ID) de associação para a estação via um quadro association response. Nesse intervalo de tempo, o AP já dispõe do endereço físico (MAC) da estação. 11 Uma vez associado, AP e estação começam a trocar dados.

Depois da associação AP1

EM (Estação Móvel)

08:00:45:37:41:7d

AP2

AP3

Endereço MAC da EM

AID

Endereço MAC do EM

AID

08:00:45:37:41:7d

Um valor de [1 a 2007)

Endereço MAC da EM

AID

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 estação serão recebidos pelo AP no qual a estação está associada (num mecanismo semelhante ao proxy-ARP). O AP, então, construirá um quadro no formato do IEEE 802.11 e o enviará à estação móvel.

Reassociação 11 Quando a estação se desloca, pode haver necessidade de mudança de AP.

q

11 A reassociação é o processo de mudar a associação de um AP antigo para um novo AP quando uma estação móvel estiver se deslocando entre áreas distintas. 11 Também pode ocorrer quando a estação sai temporariamente da área de um AP e retorna.

A reassociação define o processo pelo qual uma estação muda sua associação de um AP a outro. Apesar de cada fabricante utilizar mecanismos proprietários para realizar a reassociação, o nível do sinal recebido entre AP e estação continua sendo um dos fatores determinantes para esse mecanismo ocorrer sem interrupção. A reassociação também pode ser usada por uma estação quando, por algum motivo, esta perde conectividade com o AP. Como o AP já havia autenticado e associado a estação anteriormente, ela não precisa passar por todo o processo de autenticação/associação novamente. Ao se reassociar, a estação móvel envia para o novo AP o endereço do AP antigo. Isso permite que o AP antigo encaminhe eventuais quadros remanescentes, destinados à estação.

Capítulo 2 - Redes sem fio IEEE 802.11

11 APs adjacentes podem interagir uns com os outros durante essa operação.

21

Desassociação e Desautenticação 11 Para o AP terminar uma associação ou autenticação, ela usa os quadros de

q

disassociation e deauthentication. 11 Um campo chamado reason code traz o motivo. É possível que um AP queira terminar uma associação ou autenticação. Para isso, ele usa os quadros de desassociação (disassociation) e desautenticação (deauthentication). No único campo desses quadros, o reason code, vem o motivo do término da relação.

Hand over 11 Apesar de não definir como deve ser feito, o IEEE 802.11 traz a base para um meca-

q

nismo de mobilidade semelhante ao da rede celular. 11 Estações móveis 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 posição da estação e receber quadros armazenados O IEEE 802.11 permite o hand over (isto é, mobilidade) no nível de enlace. Uma estação móvel 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 reassociação, que permite que o estado (se existir) seja exportado de um AP para outro.

IEEE 802.11 – Camadas PHY e MAC 802.2 LLC

Camada de Enlace (MAC)

802.11 MAC

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

802.11 FHSS

22

802.11 DSSS

802.11a OFDM

802.11b HR/DSSS

802.11g ERP

Figura 2.12 Camadas PHY (física) e MAC do padrão 802.11.

Camada Física (PHY)

O padrão IEEE 802.11 descreve a camada física e a camada MAC de uma rede sem fio. Em termos do modelo de referência OSI, a camada física (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 padrão IEEE 802.2, conforme ilustra a Figura 2.12. A camada física é responsável pela codificação e transmissão dos dados no meio físico, ou seja, descreve as técnicas de codificação e modulação. Assim, enquanto a camada física trata de bits, na camada de enlace, a unidade de informação é o quadro (frame). A rigor, o termo pacote deve ser usado apenas no contexto da camada três (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 física (PHY) 11 Diz respeito às técnicas de transmissão e modulação. 11 Camada 1 do modelo OSI de referência.

q

q

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 evolução o padrão IEEE 802.11 incorporou uma série de técnicas de modulação e codificação distintas. Redes 802.11 utilizam duas faixas do espectro de uso não licenciado na maior parte do mundo, inclusive no Brasil. Essas faixas são chamadas Industrial, Scientific and Medical (ISM) e, como o nome indica, são reservadas para uso industrial, médico e científico, e podem ser usadas por qualquer dispositivo, contanto que a potência transmitida não ultrapasse certos valores legais. A primeira é a chamada banda S-ISM, que abrange as frequências entre 2,4 e 2,5 GHz. Essa é a faixa utilizada pelas implementações 802.11b e 802.11g. Trata-se de uma porção do espectro com diversos dispositivos emitentes, como fornos de micro-ondas e alguns modelos de telefones sem fio. É também usada por dispositivos IEEE 802.15.1 (bluetooth). Por conta de seu uso não 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 características de propagação e o baixo poder de penetração dessas frequências implicam a necessidade de visada direta para distâncias maiores do que algumas dezenas de metros, considerando as potências legalmente aceitáveis. 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 frequências entre 5,725 e 5,875 GHz. Os dispositivos 802.11a não alcançaram a mesma popularidade dos dispositivos 802.11b ou 802.11g e também por isso sua operação está menos sujeita a interferência, apesar de a necessidade de visada direta ser ainda maior nessas frequências.

Canais na faixa de 2,4 GHz Canal

1

2

3

4

5

6

7

8

9

10

11

Freq.

2412

2417

2422

2427

2432

2437

2442

2447

2452

2457

2462

Central

Canais Figura 2.13 Demonstração dos canais da faixa 2,4GHz.

1

2

3

2,412

4

5

6

2,437

7

8

9

10

11

2,462

Freq (GHz)

Na faixa de 2,4GHz, cada canal está separado por 5MHz. Assim, o canal 1 tem a frequência central em 2.412MHz, enquanto a frequência central do canal 2 é 2.417MHz (2.412+5). No entanto, os padrões “b” e “g” empregam canais de transmissão com 22MHz de largura, o que implica que uma transmissão em um canal usará frequências de canais adjacentes,

Capítulo 2 - Redes sem fio IEEE 802.11

(MHz)

como indicado na Figura 2.13. 23

É fácil ver que uma separação de cinco canais é necessária para que duas transmissões possam ocorrer simultaneamente. Por esse motivo, é sugerido o uso dos canais 1, 6 e 11, chamados canais ortogonais ou não interferentes, quando se pretende a instalação de várias redes ou pontos de acesso próximos. Apesar de no Brasil a Anatel regulamentar apenas o uso de 11 canais, existem países, como o Japão, onde 14 canais estão disponíveis para o uso de redes Wi-Fi.

Canais na faixa de 5GHz Canal

36

40

44

48

52

56

60

64

Freq.

5180

5200

5220

5240

5260

5280

5300

5320

Central (MHz)

5 MHz

5180 MHz

5200 MHz

5220 MHz

5240 MHz

5260 MHz

5280 MHz

5300 MHz

Figura 2.14 Demonstração dos canais da faixa 5GHz.

5320 MHz

Canais do padrão 802.11a Na faixa de 5GHz, os canais são numerados também em intervalos de 5MHz, iniciando do canal 0 (frequência central 5.000MHz até o canal 199 (frequência central em 5.995MHz). No padrão 802.11a os canais têm 20MHz de largura, o que também implica a interferência Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

entre canais adjacentes, por isso, os canais para Wi-Fi nessa faixa são alocados com inter-

24

valos de quatro canais: 36, 40, 44 etc. Na verdade, a banda de 5GHz é subdividida em três subfaixas, onde o limite de potência 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 (frequência central 5.180MHz, seguido pelo 40, 44, e assim por diante, até o canal 64). As outras subfaixas são 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 não 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.

q

11 Controle de taxa é item sensível.

q

22 Interoperabilidade. 22 Compromisso entre eficiência e robustez. A possibilidade de estações operando com codificações diversas coexistirem na mesma rede aumenta a complexidade dos projetos práticos de redes sem fio. A necessidade de todas as estações, seja qual for sua taxa de associação (isto é, a codificação sendo usada para comunicação entre dois pares), reconhecerem as informações de controle obriga o uso da codificação na taxa base para os dados de controle, sendo que a taxa base é a mais baixa suportada pelo padrão. O resultado é que a taxa nominal é muito maior do que a efetivamente disponível como banda útil para dados. Por isso, os cálculos de disponibilidade de banda são complexos, visto ser impossível definir, a priori, qual será a taxa de associação das diversas estações. Os pontos de acesso possuem mecanismos que permitem estabelecer uma taxa de associação mínima. Esses mecanismos são úteis porque impedem que estações muito afastadas se associem a um ponto de acesso usando uma taxa baixa, o que diminuiria a disponibilidade de banda para todas as estações associadas àquele ponto de acesso. Essa restrição tende a reduzir o raio de associação (a distância que uma estação 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 conexões intermitentes, já que flutuações do nível de sinal são norma para redes sem fio. Além disso, a taxa de transmissão entre uma estação e um ponto de acesso deve satisfazer um compromisso delicado. Transmissões a taxas mais baixas são mais robustas (menos susceptíveis a erros), mas ocupam o meio por mais tempo, ao passo que transmissões a taxas maiores fazem uso mais eficiente do meio compartilhado, mas são mais susceptíveis a erros. O algoritmo de adaptação de taxa, cujo trabalho é encontrar essa taxa de transmissão ótima, não faz parte do padrão IEEE 802.11, ficando sua implementação a cargo dos fabricantes de dispositivos Wi-Fi.

Camada MAC 11 A camada MAC define as regras para uso compartilhado do meio.

q

22 MAC = Medium Access Control (Controle de Acesso ao Meio). 11 A ideia é evitar colisões (em vez de detectá-las). 22 Ethernet – CSMA/CD (detecta colisão).

11 Também é importante aumentar a confiabilidade. 22 Perda de quadros por corrupção é mais comum em redes sem fio. Apesar dos objetivos comuns, o controle de acesso ao meio descrito no padrão IEEE 802.11 difere do descrito na respectiva camada MAC do padrão IEEE 802.3 (Ethernet) justamente por conta das características do meio de propagação sem fio. A transmissão de rádio, em espaço livre, traz desafios que uma rede cabeada não apresenta. Em uma rede Ethernet é possível detectar durante a transmissão quando uma colisão ocorreu e, dessa forma, retransmitir os quadros perdidos. Em redes sem fio, no entanto, isso não acontece. Transmissores de rádio não são capazes de escutar o meio ao mesmo tempo em que

Capítulo 2 - Redes sem fio IEEE 802.11

22 Wi-Fi – CSMA/CA (evita colisão).

transmitem, o que dificulta uma proposta de detecção de colisão. Além disso, os custos de 25

uma colisão em redes sem fio são altos se comparados aos mesmos custos em uma rede cabeada, onde as taxas de transmissão são usualmente maiores. Até porque a perda de quadros por corrupção na transmissão é um evento raro em redes cabeadas e relativamente comum em redes sem fio.

CSMA/CA

q

Carrier Sense Multiple Access with Collision Avoidance: 11 Escuta o meio. 11 Está livre por um tempo maior que DIFS? 22 SIM – transmite. 22 NÃO – entra em regime de backoff.

Para finalizar nossa descrição da camada MAC do IEEE 802.11, falta descrever a forma como as estações disputam o meio quando desejam transmitir. Ou seja, devemos detalhar o funcionamento da função de coordenação distribuída (Distributed Coordination Function – DCF) do padrão de uma forma algorítmica. Quando uma estação deseja transmitir, ela escuta o meio para determinar se há outra transmissão em curso. Se o meio estiver livre há pelo menos um intervalo de tempo DIFS (DCF Interframe Space), a estação transmite seu quadro imediatamente. No entanto, se a estação detecta o meio como ocupado, ela deverá entrar em um regime de backoff. Nesse estado, a estação deverá sortear uma quantidade aleatória de slots de tempo, que deverá observar após o meio ser detectado como livre. Ou seja, mesmo depois da transmissão corrente terminar, a estação aguardará um tempo aleatório antes de iniciar sua transmissão. Esse mecanismo foi concebido para reduzir a probabilidade de colisões, já que existe a possibilidade de outras estações também estarem aguardando para transmitir (disputa pelo meio). Figura 2.15 Diferentes backoffs na transmissão de cinco estações.

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

O backoff exponencial

26

SIFS + ACK + DIFS

A

Frame

Frame

B Backoff C

Frame

Frame

D

Frame

E

TEMPO

Na Figura 2.15, é possível avaliar a atividade de cinco estações na transmissão de seus dados. O sistema começa com uma estação A transmitindo um quadro. Ao término desse quadro, todas as estações esperam o SIFS + ACK + DIFS (SIFS – Short IFS; ACK – acknowledgement). Nesse momento, as estações que possuem dados para transmitir escolhem tempos aleatórios (backoffs); na figura claramente podemos ver que a estação C escolhe um tempo menor, em segundo lugar a estação D e em seguida a estação B. Após decrementar o valor de backoff, a estação C escuta o meio e verifica se nenhuma outra estação está transmitindo, e aí transmite seus dados. Ao final da transmissão da estação C, todas as estações aguardam SIFS + ACK + DIFS. Observe que nesse momento a estação E tem dados para transmitir. Todos os tempos de backoff serão decrementados e a estação D chegará primeiro ao fim desse período e fará a transmissão. No próximo intervalo, a estação E transmite e por último a estação B transmite. Esse exemplo é ilustrativo de como a injustiça com a estação B, em média, não existe para um grande período de tempo de observação.

O quadro 802.11

q

11 O cabeçalho MAC tem 30 bytes. 11 Provisão para quatro endereços. 11 4 bytes ao final para verificação de integridade (CRC). 11 O corpo do quadro tem até 2312 bytes. 22 Esse tamanho é aumentado para 7995 (emenda n). Cabeçalho MAC 2

2

6

6

6

6

2

0-2312

4

Quadro de Controle

Duração/ID (ou Identificador)

Endereço 1

Endereço 2

Endereço 3

Número de Sequência

Endereço 4

Corpo do Quadro

FCS

A Figura 2.16 mostra o formato de um quadro IEEE 802.11. Uma das características mais importantes é a presença de quatro endereços MAC (ADDR1-4). Enquanto em uma rede Ethernet só são necessários dois endereços 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 intermediários (como pontos de acesso). Esses intermediários são o destino imediato do pacote, mas não seu destino final. Assim, é necessário apontá-los, bem como identificar o destino final para que o quadro chegue a ele. Os endereços são numerados, em vez de terem um nome, porque sua função varia de acordo com o tipo do quadro. Geralmente, o endereço 1 (ADDR1) é o destino imediato do pacote (isto é, identifica o receptor), o endereço 2 (ADDR2) identifica o transmissor e o endereço 3 é usado para filtragem no receptor. Cada endereço pode ter uma das seguintes funções: 11 Endereço de destino: destino final do quadro. 11 Endereço de origem: endereço de quem gerou o quadro. 11 Endereço do receptor: qual estação deve processar o quadro. 11 Endereço do transmissor: qual estação enviou aquele quadro. 11 Identificação do Basic Service Set (BSSID): como várias redes locais podem compartilhar a

Capítulo 2 - Redes sem fio IEEE 802.11

Figura 2.16 Formato do quadro 802.11.

mesma área, esse endereço permite identificar em que rede sem fio o quadro é transmitido. 27

A maior parte dos quadros usa três endereços (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 transmissão corrente, ao passo que o Sequence Control carrega informações para remontagem do quadro, caso ele tenha sido fragmentado e também ajuda na identificação de quadros duplicados. Após o corpo (Frame Body), o quadro traz um checksum baseado em Cyclic Redundancy Check (CRC), que permite a verificação de integridade (se o quadro foi corrompido durante a transmissão). O corpo do quadro em si aumenta de 2312 (tamanho máximo) para 7995, quando a emenda “n” for utilizada.

Endereços MAC 11 Endereços MAC estão para os quadros IEEE 802.11 como os endereços IP estão para

q

os pacotes IP. 11 Endereços de 48 bits (6 bytes). 11 Duas partes: 22 OUI – identifica fabricante (3 bytes). 22 Últimos 3 bytes identificam dispositivo. Assim, como no padrão Ethernet, o 802.11 utiliza endereços MAC de 48 bits para identificar dispositivos. Estes são divididos em duas partes, sendo que a primeira metade identifica um fabricante, enquanto o restante designa um dispositivo. A não ser por fraudes ou erros na fabricação, cada dispositivo Wi-Fi tem um endereço único.

Endereço de destino

q

11 Unicast: um destinatário. 22 Primeiro byte par (exemplo 00:01:02:03:04:05). 11 Multicast: diversos destinatários.

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

22 Primeiro byte ímpar (exemplo 01:02:03:04:05:06). 11 Broadcast: todos. 22 FF:FF:FF:FF:FF:FF

Unicast

Multicast

Broadcast

Quadros podem ser destinados a um destinatário único ou a um grupo de destinatários. No primeiro caso, teremos uma transmissão unicast e, portanto, um endereço de destino unicast. As transmissões para grupos são chamadas de multicast. Um caso particular das transmissões multicast de especial interesse é o broadcast – uma transmissão destinada para todos os participantes de uma rede. Nos endereços de unicast, o primeiro bit transmitido é sempre um 0, ao passo que nos endereços de multicast o primeiro bit é 1. O endereço de broadcast tem todos os bits iguais a 1 (FF:FF:FF:FF:FF:FF, em notação hexadecimal). Como os bytes dos endereços são transmi-

28

Figura 2.17 Ilustração do envio em Unicast, Multicast e Broadcast.

tidos na ordem reversa, o primeiro bit transmitido será o bit menos significativo do primeiro byte, por isso, os endereços unicast terão o primeiro byte par (um número binário, cujo bit menos significativo é zero, é sempre um número par). No 802.11 todos os quadros unicast devem ser confirmados pelo destinatários. Ou seja, ao receber um quadro endereçado exclusivamente a ele, o dispositivo deve responder com um quadro especial, chamado acknowledgment (ack). Quadros para endereços de grupo não precisam ser confirmados.

Vazão efetiva das redes Wi-Fi Data Throughput 12 11 10 9 8 Mbits/s

7 6 5 4 Tempo ocioso Preâmbulo PLCP Cabeçalho PLCP Cabeçalho MAC + ACK Cabeçalho LLC/SNAP Cabeçalho TCP/IP Dados

2 1 0 1

2

5,5

11

Mbits/s

O gráfico de barras da Figura 2.18 mostra a eficiência percentual de cada uma das taxas de uma rede IEEE 802.11b. Observe que a menor eficiência existe para a taxa de 11 Mbps. Isso acontece porque parte dos cabeçalhos são transmitidos a taxas mais baixas, provocando forte deterioração. Fica claro pelo gráfico que existe grande penalidade para as estações que estão nessa taxa. Para as taxas menores, essa perda é proporcionalmente menor. Observe que, no caso de redes IEEE 802.11g operando com estações IEEE 802.11b, existe forte deterioração. Não se pode esperar que exista grande desempenho quando as duas redes são misturadas. Como dissemos, existem APs que permitem estabelecer a menor taxa com a qual um usuário poderá se associar ao AP. Essa função é especialmente interessante para evitar degradação da rede com a presença de usuários de baixa taxa. Essa situação, caso não seja resolvida de outra forma, deve ser considerada de modo bastante sério. Essa preocupação é maior para ambientes com grande mobilidade dos usuários, uma vez que existe mistura grande de perfis. Nesse caso, a alteração da posição dos usuários pode prejudicar o desempenho da rede como um todo. No entanto, vale lembrar que a coibição do uso de taxas menores resulta em diminuição da área de cobertura da rede sem fio, já que as transmissões a taxas menores têm maior alcance.

Capítulo 2 - Redes sem fio IEEE 802.11

Figura 2.18 Overhead de transmissão no padrão 802.11b em suas diversas taxas.

3

29

Segurança em redes IEEE 802.11 11 O problema da segurança é mais grave nas redes sem fio.

q

11 Os padrões de segurança. 22 WEP (obsoleto). 22 A emenda “i” surgiu para melhorar a segurança das redes IEEE 802.11. 33 WPA1: retrocompatibilidade com hardware legado. 33 WPA 2: novos algoritmos para um novo hardware. 33 WPA Personal: autenticação baseada em chave pré-compartilhada. 33 WPA Enterprise: uso de servidor de autenticação.

O problema da segurança 11 O tráfego não é confinado.

q

22 Não é necessário o acesso físico à infraestrutura. 11 Os três objetivos básicos da segurança: 22 Privacidade: garantia de sigilo das mensagens. 22 Integridade: mensagens não adulteradas. 22 Autenticidade: agentes devidamente identificados. Segurança é um tópico de extrema importância em redes de computadores. Os procedimentos e técnicas de segurança existem para combater o mau uso dos recursos compartilhados, afastar usuários 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 indivíduo, máquina ou programa é de fato quem afirma ser. Os objetivos acima são comuns a todas as redes de computadores, mas são mais difíceis de alcançar em redes sem fio. Quando a conexão entre os computadores em uma rede é

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

feita através de cabos, a sua invasão só é possível através do acesso direto à infraestrutura cabeada, mas em redes sem fio, onde a comunicação é feita pelo ar, a segurança se torna mais importante e complicada. Na ausência de um mecanismo de segurança, qualquer indivíduo com uma antena e um receptor de rádio sintonizado na frequência de operação correta pode interceptar a comunicação ou utilizar os recursos dessa rede. O problema clássico da segurança costuma ser dividido em: garantir privacidade (os dados só podem ser acessados pelo remetente e pelo destinatário legítimos); integridade (os dados não são adulterados) e autenticidade (os agentes envolvidos são de fato quem afirmam ser). Nossa principal preocupação neste curso está ligada às questões de autenticação, que serão abordadas novamente, e em maior profundidade, na próxima seção.

Problemas típicos das redes sem fio 11 Associação não autorizada. 22 Proposital. 22 Acidental. 11 Negação de serviço (Denial of Service – DoS). 22 Voltada aos elementos da rede (ponto de acesso). 22 Voltada ao espectro (jamming). 11 Interceptação de tráfego.

30

q

Além de todos os problemas usuais das redes cabeadas, em redes sem fio existem outros específicos. O mais típico problema de segurança nas redes Wi-Fi é o simples uso não autorizado, através da associação 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 comparação às redes cabeadas, e também porque a conexão do vizinho tende a ser mais lenta (por conta da distância), essa conexão clandestina penalizará o usuário legítimo. Esses acessos clandestinos são, em muitos casos, não intencionais. Muitos sistemas estão configurados para tentarem a associação automaticamente ao ponto de acesso com sinal mais forte. A negação de serviço é uma técnica de agressão cujo objetivo é tornar uma rede ou recurso da rede inviável. O Denial of Service (DoS) não é um problema exclusivo das redes sem fio, mas nelas é mais grave por duas razões 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 inviável e (2) um dispositivo que gere ruído na faixa de frequências onde a rede opera (jamming) pode ser utilizado sem a necessidade de qualquer técnica computacional de segurança e mesmo sem a necessidade do acesso físico – uma antena direcional pode convergir a energia na área da rede e inviabilizá-la. Finalmente, a interceptação de tráfego em uma rede sem fio pode ser realizada com relativa facilidade. Basta acessar o canal correto. Novamente o acesso físico pode não ser necessário, bastando o uso de antenas adequadas por parte do agressor.

Padrões de segurança no Wi-Fi Cronologia dos mecanismos de segurança:

q

11 WEP. 22 1997 – parte do padrão. 11 WPA. 22 2002 – baseado em um draft do IEEE 802.11i. 22 Personal e Enterprise. 11 WPA2. 22 2004 – versão final do IEEE802.11i. 22 Personal e Enterprise. O primeiro padrão de segurança, o Wired Equivalent Privacy (WEP), era parte integral do padrão original IEEE 802.11, lançado em 1997. A promessa, ao menos no nome, era prover um grau de segurança equivalente ao de uma rede cabeada, mas, como veremos, esse

Diante do fracasso do WEP, o IEEE formou a força tarefa “i” (TGi – Task Group i) para propor mecanismos de segurança mais efetivos. Uma versão preliminar (draft) da emenda “i” foi a base para o que a Wi-Fi Alliance batizou como Wi-Fi Protected Access (WPA), lançado no final de 2002 e disponível 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).

Capítulo 2 - Redes sem fio IEEE 802.11

objetivo não foi alcançado.

31

WEP

q

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 padrão IEEE 802.11, de 1997.

Para garantir que apenas os usuários autorizados pudessem ter acesso à rede, o WEP exige que uma senha seja configurada no ponto de acesso e distribuída para todos os usuários. 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 conteúdo do quadro foi o RC4. Para garantir que o conteúdo do quadro não 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.

q

22 Algoritmo de criptografia de fluxo (streamcipher). 22 Muito utilizado (SSL e TLS). 11 Tamanho das chaves criptográficas é: 22 40 (64 - 24) bits.

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

22 104 (128 -24) bits.

32

mensagem

chave

mensagem cifrada

1

1

0

0

1

1

1

1

0

0

0

1

1

0

0

1

1

0

0

0

1

XOR

O algoritmo de criptografia escolhido pelo padrão foi o RC4 (Ron’s Cipher 4), empregado em diversas outras aplicações, 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 criptográficos, a mensagem é combinada com um fluxo contínuo 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 necessárias. O mecanismo é muito simples, mensagem e chave são combinadas por uma operação binária 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 Operação de cifragem da mensagem realizada pelo WEP, baseada na operação XOR.

Há certa confusão em relação ao tamanho das chaves. Existem duas alternativas, as chaves de 40/64 bits ou as chaves de 104/128 bits. A confusão vem do fato de o usuário informar apenas uma parte da chave, que é complementada por um elemento chamado vetor de inicialização, que tem 24 bits. Assim, no caso de uma senha de 128 bits, o usuário escolherá apenas 104, ao passo que no caso das chaves de 64 bits, ele escolherá apenas 40 bits.

WEP: integridade O mecanismo de verificação de integridade é o CRC32.

q

11 Fácil e rápido de calcular. 11 Criptograficamente fraco. 22 Não impede adulteração transparente do quadro. O Cyclic Redundancy Check (CRC) é um mecanismo de verificação 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 destinatário repete o mesmo cálculo. Se encontrar um CRC diferente do recebido isso indicará que o quadro (ou o próprio CRC) foram alterados. A alteração pode acontecer intencionalmente (causada por um agressor) ou acidentalmente (quadro corrompido, por exemplo, pela presença de ruídos durante a transmissão). O CRC pode ser comparado aos dois dígitos finais de um CPF, que são calculados em função 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.

q

22 Chaves curtas. 22 Reúso frequente das chaves. 22 Uso prolongado das chaves. 11 CRC não é forte o suficiente. 11 Vetor de inicialização. 22 Revela parte da senha. 11 PSKs são intrinsecamente inseguras. Dado o poder computacional atual dos computadores pessoais, chaves de 40 bits são demasiadamente curtas. Mesmo as de 104 bits não são fortes o suficiente. Para piorar, o WEP possui deficiências que o tornariam vulnerável mesmo com chaves mais longas.

algoritmo RC4, que é considerado razoavelmente seguro, não foi implementado da forma correta e tornou-se ineficaz. Além disso, como dissemos, o CRC é uma técnica incapaz de proteger o quadro contra adulterações. Outra série de problemas do WEP está ligada a um elemento chamado Vetor de Inicialização. Esse campo do quadro WEP é transmitido em texto plano (sem criptografia) e consiste nos primeiros 24 bits da chave criptográfica. Revelar uma parte da chave auxilia no processo de criptoanálise (ataque à criptografia). Finalmente, o uso de chaves pré-compartilhadas é um procedimento intrinsecamente inseguro. Afinal, as chaves têm de ser escolhidas pelo administrador da rede, configuradas

Capítulo 2 - Redes sem fio IEEE 802.11

O reuso frequente de uma chave, e por períodos longos, a torna vulnerável. Em síntese, o

33

no ponto de acesso e distribuídas para todos os usuários. A experiência mostra que essas chaves dificilmente são trocadas com a periodicidade recomendada. E, por último, um segredo compartilhado não é um segredo.

WPA 1 O IEEE reconheceu as deficiências do WEP e criou a TGi (força-tarefa “i”).

q

11 O WPA 1 foi lançado em 2002 baseado numa versão 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 continuaram sendo percebidas como inseguras durante muitos anos, apenas recentemente tendo vencido esse estigma. Uma preocupação 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 lançados com WEP, bastando uma alteração 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 padrões atuais, provê um nível de segurança aceitável para a maioria das redes. O novo protocolo de criptografia, TKIP, é abordado a seguir.

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

WPA 1: TKIP

34

Novo esquema para verificação de integridade da mensagem.

q

11 Michael Integrity Check (MIC) substituiu o CRC32. 11 Novo modo de escolher e utilizar os Vetores de Inicialização. 11 Cada pacote é encriptado com uma chave diferente. Para alcançar maior grau de segurança, ainda rodando sobre o hardware desenhado para o WEP, o novo protocolo batizado de Temporal Key Integrity Protocol (TKIP) incorporou uma série de mudanças. Em primeiro lugar, o fraco CRC foi substituído por um novo esquema mais forte chamado de Michael Integrity Check (MIC), mais eficiente na identificação de adulterações do quadro. O esquema de uso dos vetores de inicialização também foi alterado para dificultar a criptoanálise e o sistema passou a usar chaves temporárias, derivadas da chave original, e diferentes para cada quadro transmitido, o que aumenta muito a segurança do sistema (quanto mais é usada uma chave, mais fácil é descobri-la).

WPA 2 11 O WPA 2 é um mecanismo de segurança reconstruído do zero.

q

22 Não 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 Também existem o WPA2 Personal e o WPA2 Enterprise. Lançado em 2004, o WPA2 fechou o trabalho do TGi. O WPA2 reconstrói o sistema de segurança do Wi-Fi sem nenhuma preocupação com a retrocompatibilidade. Por isso, só é suportado por dispositivos fabricados após 2004. O coração da nova proposta é o sistema de criptografia Counter Mode with Cipher Block Chaining Message Authentication Code (CCMP) que, para começar, 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 padrão escolheu chaves de 128 bits. Chaves maiores, apesar de mais seguras, inibiriam a exportação de produtos produzidos nos Estados Unidos, já que esse país limita a exportação 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 autenticação RADIUS) – nosso próximo assunto.

WPA: Personal versus Enterprise 11 WPA “Pessoal”.

q

22 Uso de chaves pré-compartilhadas. 22 Mais fácil de implementar. 11 WPA “Empresarial”. 22 Uso de servidor de autenticação RADIUS. 22 Cada usuário tem sua senha. Uma característica do WEP que o WPA ainda preserva é o esquema de chaves pré-compartilhadas, considerado não ideal para aplicações de segurança mais estritas. Mas uma alternativa também foi oferecida pelo padrão – o uso de servidores de autenticação.

não. Nesse caso, os usuários têm senhas individuais, além da chave da rede, provendo uma camada adicional de segurança. Para implementar o servidor de autenticação, 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 serviço eduroam.

Capítulo 2 - Redes sem fio IEEE 802.11

Um servidor de autenticação recebe pedidos de autenticação dos usuários e os valida ou

35

WPA Enterprise: esquema Rede Sem Fio Autenticador 1 2

Servidor de Autenticação (RADIUS)

Figura 2.20 Esquema de passos para a autenticação WPA Enterprise, com servidor RADIUS.

Suplicante Internet 3

A Figura 2.20 ilustra o mecanismo de autenticação de usuários 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 após a associação ao ponto de acesso, que, nesse caso, age como o autenticador. O papel do autenticador é permitir a conexão do suplicante com o servidor de autenticação e bloquear todo o tráfego do suplicante que não seja referente à autenticação. Se o servidor de autenticação liberar o acesso, o suplicante poderá usufruir de todos os serviços da rede. Caso contrário, será desassociado pelo ponto de acesso.

IEEE 802.1X e EAP 11 IEEE 802.1X.

q

22 Padrão IEEE para autenticação de usuários. 22 Baseado no Extended Authentication Protocol (EAP).

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

22 É apenas um framework para diversos “métodos”. 11 Métodos EAP. 22 Uso de métodos legados. 33 TTLS e PEAP. 22 Criptográficos. 33 TLS. 22 Não criptográficos. 33 MD5 e MSCHAP. O esquema que acabamos de descrever para autenticação de usuários é, na verdade, proposto no padrão IEEE 802.1X, ou seja, não é parte do padrão IEEE 802.11 para redes sem fio, sendo também usado em outros cenários. O IEEE 802.1X é, por sua vez, baseado no Extended Authentication Protocol (EAP) o que, em termos práticos, significa que ele não descreve o mecanismo de autenticação utilizado e sim um framework para diversos protocolos de autenticação. Esse esquema pode inclusive incorporar novos protocolos que venham a surgir. No EAP, os protocolos disponíveis são chamados de métodos. É natural que alguns métodos sejam considerados mais seguros que outros. Além disso, alguns métodos foram, na 36

verdade, concebidos para permitir a utilização de um sistema de autenticação pré-existente (sistema legado). O objetivo, nesse caso, é evitar a duplicação do sistema de autenticação mantido, por exemplo, para a rede cabeada da instituição. Dois métodos nessa categoria são o Tunneled Transport Layer Security (TTLS) e o Protected EAP (PEAP). Ambos transportam e protegem o método legado de autenticação de usuários. Nesse contexto, o padrão se refere ao método legado como “método interno”. Além disso, os métodos EAP podem ou não utilizar criptografia. Os métodos não criptográficos (como o MD5 ou o MSCHAP), devem ser usados em conjunto com outras técnicas de criptografia ou como métodos internos do TTLS ou do Peap. Métodos criptográficos são evidentemente mais seguros. Nessa classe, o exemplo mais difundido é o Transport Layer Security (TLS). Os métodos de autenticação serão estudados no próximo capítulo.

Robust Security Network (RSN) 11 Implementação completa do IEEE 802.11i.

q

22 Sem suporte a WEP. 33 Com servidor de autenticação. 11 Também descreve os mecanismos de gerência de chaves (que não fazem parte do padrão). Todos esses mecanismos de segurança descritos culminam na implementação considerada ideal de segurança, chamada Robust Security Network (RSN). O RSN é um nome curto para designar uma rede que implementa completamente o padrão IEEE 802.11i e não provê suporte a WEP. O RSN utiliza WPA (TKIP ou CCMP) com autenticação baseada em um servidor RADIUS. Além disso, uma RSN deve implementar uma série de mecanismos de gerência de chaves criptográficas (geração e distribuição) que estão fora do escopo do IEEE 802.11.

Recomendações de segurança Para as redes corporativas WPA2 Enterprise.

q

11 CCMP é mais seguro que TKIP. 11 Servidor de autenticação garante maior segurança do que as chaves pré-compartilhadas. 11 Uso de métodos criptográficos (como o EAP-TTLS e o EAP-TLS). 11 Sistema bem desenhado para gerência de chaves. 11 Para as redes domésticas: WPA2 Personal com senhas difíceis, trocadas com frequência.

que os recursos necessários para sua implantação estão disponíveis? Esse sistema seria uma rede utilizando CCMP (WPA2) e servidor de autenticação, além de um mecanismo de autenticação protegido por EAP-TTLS. Mas essa configuração, além de mais difícil de implementar, implica o uso de um servidor RADIUS. Assim, para o usuário doméstico, é preciso propor um cenário mais simples. Esse cenário, considerado seguro o suficiente para o uso não comercial, seria o emprego de WPA (de preferência WPA 2), com um cuidado especial dedicado às senhas pré-compartilhadas (que sejam complicadas e trocadas com frequência).

Capítulo 2 - Redes sem fio IEEE 802.11

O que seria, portanto, um sistema de segurança ideal para uma rede sem fio, considerando

37

Requisitos eduroam

q

11 Suporte à autenticação robusta. 22 Servidor RADIUS. 22 IEEE 802.1X. 22 IEEE 802.11i. 11 Comumente chamado WPA2 Enterprise. 11 Essas funcionalidades são encontradas em parte considerável dos APs “consumer grade”.

Para poder ser utilizado no eduroam, um ponto de acesso tem de suportar os padrões IEEE 802.1X e IEEE 802.11i (WPA2 Enterprise). Felizmente, boa parte dos pontos de acesso, mesmo os “consumer grade”, suportam esses padrões.

Atividade Prática 1 e Configurar AP para autenticar em servidor RADIUS Resumo dos dados utilizados nesta atividade prática Senha compartilhada entre AP e FreeRADIUS.

eduroam123

SSID

eduroamXX (exemplo: para IP 10.88.193.137 = “eduroam137”)

Tipo de segurança no ponto de acesso.

WPA2 Enterprise/AES

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

Ponto de Acesso

38

Usuário

Servidor RADIUS Instituição 1

As práticas visam preparar cada aluno para instalar e manter o serviço eduroam em uma instituição de ensino e pesquisa. A Figura 2.21 mostra como é feita a configuração de um ponto de acesso para que o pedido de autenticação seja tratado no servidor RADIUS. Esta prática mostra também as configurações necessárias no servidor RADIUS para aceitar pedidos de autenticação de um determinado ponto de acesso.

Cadastrando o AP no servidor RADIUS Para permitir que um servidor RADIUS aceite requisições de autenticação de um ponto de acesso específico, é necessário cadastrar o ponto de acesso na lista de possíveis clientes do servidor RADIUS. Nesta prática, este passo será realizado pelo professor em um servidor FreeRADIUS previamente criado. Em prática realizada adiante, o aluno irá configurar o servidor RADIUS. Considerando o uso do software FreeRADIUS, a seguir podemos visualizar as linhas que deverão ser incluídas no arquivo /etc/freeradius/clients.conf do servidor RADIUS, devendo

Figura 2.21 Prática de configuração do ponto de acesso para acesso ao servidor RADIUS existente.

conter, portanto, o IP do ponto de acesso, a senha compartilhada e configurada no ponto de acesso, assim como seu nome. Nas práticas futuras o aluno sempre terá que configurar informações dos dispositivos NAS (por exemplo ponto de acesso) no arquivo clients.conf.

client 192.168.0.3 { secret



= eduroam123

shortname



= eduroam-uff-1

nastype

= other

} A seguir é apresentado como é feita a configuração de um ponto de acesso com o firmware baseado em Linux DD-WRT.

Configurando roteador com DD-WRT Como primeiro passo temos a identificação do IP, que será aquele cadastrado no arquivo clientes.conf citado anteriormente. Perceba que o IP a ser informado ao professor para liberação no FreeRADIUS é aquele referente à porta WAN.

O segundo passo compreende a alteração do SSID da rede, ou seja, o nome que será divulgado aos clientes para se conectarem. Na configuração em laboratório usaremos algo como “eduroamXX”, onde “XX” pode representar o valor decimal do último byte do endereço IP do ponto de acesso. Por exemplo, para um IP 10.88.193.137 o SSID ficaria “eduroam137”. Lembrando que esta configuração visa somente a diferenciação dos pontos de acesso no laboratório, na rede de uma instituição real, o SSID deve sempre ser divulgado como “eduroam” (usando letras minúsculas), a fim de garantir a transparência no acesso dos usuários. Portanto, para a configuração 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 configuração com a “Apply Settings” e “Save”.

Capítulo 2 - Redes sem fio IEEE 802.11

Figura 2.22 Identificação do IP do ponto de acesso.

39

Figura 2.23 Configuração do SSID a ser utilizado pelo ponto de acesso.

Finalizando a configuração do ponto de acesso para a autenticação dos clientes no servidor RADIUS pré-existente, temos o apontamento do endereço do IP do servidor RADIUS do professor e a seleção do tipo de segurança suportado pelo ponto de acesso. Como padrão do projeto, estaremos utilizando o suporte ao 802.1X por meio do “WPA2 Enterprise” como modo de segurança e o algoritmo de segurança “AES”. Caso o modo de segurança ou o algoritmo de segurança esteja selecionado de forma diferente no ponto de acesso e no suplicante (veremos a configuração dos suplicantes em um capítulo mais à frente), a rede será exibida como indisponível para o usuário, impossibilitando a conexão. Sendo assim, atente para a utilização do “WPA2 Enterprise/AES”.

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

Navegando pelas abas “Wireless” e “Wireless Security” chegamos ao ponto de configuração,

40

onde deve-se selecionar o modo de segurança como “WPA2 Enterprise” e o algoritmo WPA como “AES”. Feito isso, é necessário informar o endereço IP do servidor de autenticação RADIUS (IP do servidor do professor). Devemos também 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”).

Figura 2.24 Configuração da comunicação 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 máquina cliente, e após adquirido o IP, acesse o endereço 192.168.1.1 pelo seu navegador. Para que o sistema funcione da maneira almejada, o ponto de acesso sem fio também deve ser configurado de forma que encaminhe as requisições para o servidor de autenticação. A

Figura 2.25 Habilitando a segurança 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 autenticação RADIUS. Isso nos provê uma série de recursos adicionais, como a possibilidade de definirmos uma senha diferente para cada cliente. Uma vez selecionada essa opção, outras aparecerão, como na Figura 2.25.

Capítulo 2 - Redes sem fio IEEE 802.11

opção que permite tal configuração está em Wireless/Wireless Security, como na Figura 2.24.

41

Em WPA Algorithms, selecionaremos AES, que nada mais é do que um algoritmo de criptografia simétrica que será utilizado para proteger as informações trocadas entre o ponto de acesso e o servidor. No RADIUS Server Address colocaremos o endereço IP do servidor RADIUS, que é para aonde o ponto de acesso encaminhará as requisições feitas pelos clientes. Em RADIUS Port, colocaremos a porta pela qual o servidor RADIUS estará ouvindo as requisições. Em Shared Key, colocaremos a chave simétrica que o ponto de acesso utilizará para se comunicar com o servidor RADIUS. O campo Key Renewall Timeout não precisa ser alterado. Com isso, encerra-se a etapa de configurações propostas neste capítulo. Através delas, é possível realizar autenticação e autorização, por intermédio do servidor RADIUS e com consulta a uma base de dados LDAP, ou seja, utilizando as configurações propostas no serviço eduroam. Agora, cada usuário pode acessar a infraestrutura de rede sem fio com o login e senha Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

cadastrados na base LDAP. Como primeiro método de autenticação será utilizado o

42

EAP-TTLS e, como segundo método, será utilizado o PAP. Esses métodos serão detalhados no próximo capítulo.

Figura 2.26 Configurando a comunicação entre o AP e o servidor RADIUS.

3 Conhecer os mecanismos de autenticação disponíveis para redes IEEE 802.11, suas diferenças e riscos associados. Compreender a autenticação utilizada no eduroam.

conceitos

Autenticação em redes sem fio. Emenda IEEE 802.11i e padrão IEEE 802.1X. Métodos EAP. Métodos internos e externos. Métodos criptográficos e não criptográficos.

Introdução Em redes sem fio, a necessidade de mecanismos robustos de autenticação é ainda maior do que em redes cabeadas. Isso ocorre porque o acesso físico a uma rede sem fio se dá pelo simples posicionamento (de um possível agressor) na área de cobertura da rede. Em seu estágio inicial, o emprego das redes sem fio foi marcado pela insegurança dos mecanismos básicos de autenticação e privacidade oferecidos pelo Wired Equivalent Privacy (WEP). Felizmente, essas falhas iniciais foram corrigidas e novos mecanismos, mais seguros, foram incorporados, conforme veremos neste capítulo.

Autenticação em redes 802.11 11 Open system:

q

22 Não provê autenticação alguma. 11 WEP – Chave compartilhada (PSK): 22 É vulnerável. 11 IEEE 802.11i = WPA: 22 Substituto para o WEP. 22 Mecanismo recomendado. O processo de autenticação mandatório previsto no padrão IEEE 802.11, chamado open-system authentication (autenticação de sistema aberto) não provê, de fato, nenhum mecanismo real ou seguro de autenticação. Trata-se tão 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 gerência e subtipo autenticação (campos do quadro 802.11), indicando o algoritmo de autenticação 0 (open system – sistema aberto). O ponto de acesso, ao receber esse quadro, registra o endereço físico do cliente como sua identificação e responde com outro quadro de gerência. O cliente,

Capítulo 3 - Métodos de autenticação

objetivos

Métodos de autenticação

por sua vez, aceita a resposta do ponto de acesso como legítima e o processo se encerra. Como 43

não há garantias de que o endereço físico (endereço MAC) do cliente seja legítimo (ele pode ser facilmente forjado), não ocorre verificação efetiva da identidade do cliente ou mesmo da rede e, portanto, esse mecanismo não deveria, a rigor, ser chamado de autenticação. Já no mecanismo de chaves pré-compartilhadas (Pre-Shared Key – PSK), um segredo (a chave criptográfica) é previamente configurado no ponto de acesso e nos clientes. A autenticação passa a ser baseada no conhecimento dessa chave. Nesse caso, o cliente também inicia a transação enviando um quadro do tipo gerência e subtipo autenticação, mas indica o algoritmo de autenticação de código 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, então, recebe o texto cifrado pelo cliente, que deve ser corretamente descriptografado pela mesma chave, a qual o ponto de acesso também conhece. O sucesso indica que o desafio foi cifrado com a chave correta e, por conseguinte, que o cliente é legítimo. Novamente, observa-se que a identidade do cliente não é efetivamente verificada. A autenticação verifica apenas se este tem em poder uma determinada informação, a chave. Além disso, novamente, não é realizada qualquer autenticação do ponto de acesso. O processo de autenticação que acabamos de descrever é parte do mecanismo Wired Equivalent Privacy (WEP), por sua vez parte das versões iniciais do padrão IEEE 802.11. Infelizmente, esse mecanismo é falho, já que a chave compartilhada pode ser obtida maliciosamente, bastando que um agressor capture os quadros da transação e se utilize de programas de quebra de senhas obtidos facilmente na internet. Por conta dessa e de outras deficiências do WEP, não apenas ligadas ao problema da autenticação, o padrão teve de incorporar novos mecanismos de autenticação. Para esse fim, como dissemos no capítulo 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.

q

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

22 Versão de 2003 deu origem ao WPA1. 22 A versão final deu origem ao WPA2. 11 Incorporado ao padrão IEEE 802.11 em 2007. 11 Autenticação baseada no padrão IEEE 802.1X. Como vimos, a emenda “i”, publicada em 2004, foi desenvolvida justamente para sanar as deficiências do WEP. No entanto, dada a debilidade do WEP e a decepção inicial com o padrão, uma versão provisória da emenda foi publicada já em 2003 com alterações compatíveis com os equipamentos já fabricados, para combater a crescente descrença na tecnologia WiFi. Essa primeira versão do IEEE 802.11i se convencionou chamar WPA1, enquanto WPA2 serve para designar a implementação final do IEEE 802.11i, que requeria mudanças no hardware dos dispositivos. Por isso, o mecanismo de autenticação do WPA1 é também baseado na ideia de chaves pré-compartilhadas (PSK). O WPA2 é a implementação completa de segurança e recomendada para o uso corporativo. Um aspecto importante é que ela permite autenticar usuários em vez de máquinas. É preciso reconhecer que os mecanismos de chave pré-compartilhada se tornam inseguros pela reutilização constante e ocasional exposição da chave (em avisos públicos ou pela divulgação boca a boca) e pela necessidade de troca constante, cada vez que um membro da equipe deixa a instituição – um procedimento raramente executado. Por esses motivos, a autenticação de usuários, como prevista no WPA2, é fundamental. Para alcançar esse 44

objetivo, o IEEE 802.11i recomenda o emprego de outra tecnologia pré-existente, o IEEE 802.1X (nesse caso, o X é maiúsculo).

IEEE 802.1X

q

11 IEEE 802.1X é um arcabouço (framework). 22 Adaptação do EAP (criado pelo IETF) (RFC 2284 – atualizado na RFC 3748). 11 O EAP é um protocolo de arcabouço. A autenticação é realizada por um protocolo de extensão – o método EAP. 11 Os métodos podem ser mais ou menos adaptados às necessidades específicas de uma rede. O IEEE 802.1X é um arcabouço (framework) de autenticação para as tecnologias de rede da

família IEEE 802, cujos membros mais notórios são o padrão Ethernet (IEEE 802.3) e o próprio WiFi (IEEE 802.11). Na verdade, o IEEE 802.1X apenas descreve o encapsulamento de um padrão pré-existente, o Extensible Authentication Protocol (EAP), sobre os padrões 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 padrão 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 não descreve um mecanismo de autenticação. Essa autenticação é realizada por um protocolo de extensão chamado de Método EAP. Os métodos podem ser mais ou menos adaptados às necessidades específicas de uma rede.

Arquitetura IEEE 802.1X a)

(PAE) Suplicante

RADIUS

EAPOL

(PAE) Autenticador

Servidor de Autenticação

Figura 3.1 Comunicação entre o suplicante, o autenticador e o servidor de autenticação RADIUS [Gant, 2002].

método EAP EAP 802.1X

802.1X

802.1 1

802.1 1

RADIUS

RADIUS

UDP/IP

UDP/IP

802.3

802.3

Na arquitetura IEEE 802.1X, chama-se de suplicante o dispositivo que busca autenticação. No caso das redes sem fio, o suplicante é o cliente que se associa à rede através de um

Capítulo 3 - Métodos de autenticação

b)

ponto de acesso. O ponto de acesso tem a função de autenticador e seu papel é intermediar 45

o processo, enviando as informações do suplicante a um servidor de autenticação, que possui a base de dados de usuários. 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 autenticação, é utilizado o protocolo RADIUS, que será estudado adiante. Assim, o autenticador, como intermediário da transação, será responsável pela tradução das mensagens EAPOL (ou EAPOW) em mensagens equivalentes do protocolo RADIUS, e vice-versa.

O protocolo EAP Link layer header

Methods

Code 1 Byte

ID 1 Byte

TLS

AKA/ SIM

Length 2 Bytes

Data 0+Bytes

Token card

EAP

Link layers

PPP

802.3

802.11

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

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

enlace, tem os seguintes campos:

46

Figura 3.2 Formato do quadro EAP.

11 Code (código) – 1 byte: indica o tipo de pacote EAP e como deve ser interpretado o campo data. Os tipos mais importantes são: 11 Tipo 1: Request (Requisição). 11 Tipo 2: Response (Resposta). 11 Tipo 3: Success (Sucesso). 11 Tipo 4: Failure (Falha). 11 ID – 1 byte: identificador para relacionar as requisições e suas respectivas respostas (retransmissões também usarão o mesmo ID). 11 Length (comprimento) – 2 bytes: número de bytes do pacote completo (incluindo Code, ID, Length e Data). 11 Data (dados) – zero ou mais bytes: sua interpretação depende do valor do campo Code. Em geral, é o campo que transporta os dados necessários para a autenticação.

Figura 3.3 EAP transporta diversos protocolos de autenticação sobre diversos protocolos de camada de enlace.

Transação EAP 11 A transação EAP se inicia logo após a associação do cliente.

q

11 Fase inicial: Identidade (Identity). 22 Requisições e respostas. 11 A seguir: negociação do método. 22 Requisições e respostas. 11 Finalizando. 22 Sucesso ou falha. A maior parte das trocas de quadros em uma transação EAP se dá através de quadros com os códigos 1: requisição (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 variável. Vejamos os tipos importantes. O tipo 1, identidade (que não deve ser confundido com o campo ID), é geralmente utilizado para iniciar o processo de autenticação. Um quadro Request/Identity (código 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 usuário (username) ou um elemento mais completo, como um identificador do tipo usuário@domínio (ao estilo de um endereço de e-mail) ou, no caso da autenticação em sistema Microsoft, de um identificador do tipo Domínio/usuário. Em resposta, o cliente deve fornecer essa identidade em um quadro Response/Identity (código 2/tipo 1). Após essa troca inicial, é preciso selecionar um mecanismo de autenticação. Na fase de negociação do método, o autenticador enviará uma requisição especificando, no campo Tipo, um determinado método EAP. Os métodos EAP correspondem aos tipos 4 em diante. Alguns tipos são 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 método solicitado não é suportado. Outro tipo importante é o tipo 3, NAK. Este é usado pelo suplicante quando o autenticador solicita um método não suportado. Nesse caso, o autenticador pode oferecer um método alternativo, enviando outra requisição com o tipo correspondente do novo método, ou

A transação EAP é encerrada pelo autenticador, que enviará um quadro com o código Sucesso (Success, código 3) ou Falha (Fail, código 4).

Capítulo 3 - Métodos de autenticação

recusar o cliente.

47

Exemplo de transação EAP

Suplicante

Autenticador

Radius

RADIUS 1:Association Request Association Response

EAPOL 2:EAPOL-Start

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

3:Request/Identity

48

4:Response/Identity

Radius-Access-Request

EAP-Request/Method

5:Radius-Access-Challenge

6:EAP-Response/Method

Radius-Access-Request

•

•

•

•

•

•

EAP-Request/Method

Radius-Access-Challenge

EAP-Response/Method

Radius-Access-Request

EAP-Success

7:Radius-Access-Acept

8:EAPOL-Key

9:DATA

• • • 10:EAPOL-Logoff

Figura 3.4 Negociação entre suplicante, autenticador e servidor RADIUS do início ao fim de uma sessão [Gast, 2002].

Vejamos o passo a passo de uma transação 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, através dos quadros de associação do padrão IEEE 802.11 (Association Request/Association Response). 2. A transação EAP se inicia propriamente com o envio, pelo suplicante, de uma mensagem

EAPOL-Start. Esse passo é omitido em algumas implementações de suplicante. 3. O Autenticador solicita que o suplicante forneça 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 autenticação 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 método a ser usado é determinado pelo servidor Radius. 6. Nessa fase, há uma série de trocas de quadros, que servirão para a autenticação pro-

priamente dita. Em alguns casos, essa etapa pode incluir mais de dez trocas. Em todos os casos, o autenticador realiza a tradução entre os protocolos EAP e RADIUS, intermediando a comunicação. Como dito, é possível que o cliente, ao ser informado dos métodos escolhidos pelo servidor RADIUS, responda com um quadro EAP-NAK, indicando sua incapacidade de prosseguir com o método. Caberá ao servidor RADIUS decidir se um método alternativo será oferecido ou se a autenticação será negada. 7. Após a verificação das credenciais, o servidor RADIUS indica sua aceitação, através 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 conexão sem fio desse ponto em diante. 9. Nesse momento, se inicia o uso efetivo da rede, por parte do cliente. Comumente essa

fase começa com a configuração de parâmetros de rede, como endereço IP (através do protocolo Dynamic Host Configuration Protocol – DHCP) e segue para as aplicações de rede, que motivaram o usuário a buscar a conexão. 10. Quando termina o interesse pelo acesso, o suplicante envia um quadro EAP-Logoff,

Métodos EAP 11 Métodos criptográficos.

q

22 PEAP, TLS e TTLS. 11 Métodos não criptográficos. 22 PAP e MsCHAPv2. 11 Esquema misto. 22 Método interno protegido por método externo. Uma das virtudes do EAP é sua flexibilidade, ou seja, o fato de oferecer diversos métodos de autenticação distintos. Esses métodos variam em complexidade de implementação e segurança oferecida. Uma importante distinção diz respeito ao emprego, ou não, de criptografia para pro-

Capítulo 3 - Métodos de autenticação

desautenticando o usuário.

teção da transação EAP. Ou seja, existem métodos criptográficos e métodos não criptográficos. 49

Métodos não criptográficos são claramente inseguros. No entanto, podem ser usados juntamente com métodos criptográficos em um esquema misto, onde o método criptográfico chamado, nesse contexto, de método de autenticação externo (outer authentication method), protege um método mais simples e possivelmente não criptográfico, o método de autenticação interno (inner authentication method), como veremos adiante. Os métodos EAP mais importantes serão estudados a seguir.

TLS (Transport Layer Security) 11 O TLS é o sucessor do SSL.

q

11 Autenticação mútua. 22 Troca de certificados. 11 Infraestrutura de chave pública (PKI) necessária. 22 Emitir e revogar chaves para usuários. O EAP-TLS foi definido na RFC 5216 e, apesar de pouco utilizado, é considerado um dos mecanismos de autenticação mais seguros para redes sem fio. O protocolo Transport Layer Security (TLS) é o sucessor do Secure Socket Layer (SSL), usado para garantir a segurança de transações na web. O mecanismo provê a autenticação mútua, do cliente e da rede, através da troca de certificados. A autenticação dupla garante não apenas a autenticidade do cliente, como também a do ponto de acesso, dificultando a inclusão de pontos de acesso clandestinos (rogue access points). Por exigir certificados de todos os clientes, o TLS é de difícil adoção, exigindo que a instituição crie sua própria infraestrutura de chave pública (PKI, do inglês Public Key Infrastructure) para gerar e distribuir os certificados além de revogar certificados comprometidos. Sua versão “tunelada”, chamada TTLS, que será abordada a seguir, simplifica alguns aspectos da adoção do TLS e, por isso, é mais amplamente utilizada.

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

TTLS e PEAP 11 TTLS = tunneled TLS (TLS “tunelado”).

q

11 PEAP = Protected EAP. 11 Em ambos, dois mecanismos de autenticação são usados: 22 Método de autenticação externa (outer). 33 Criação de túnel TLS. 22 Método de autenticação interna (inner). 33 Métodos não criptográficos podem ser usados. 11 A diferença entre TTLS e PEAP está na forma como o protocolo interno é usado. Para as instituições que já possuem sistemas de autenticação, criados para acesso a conteúdos e serviços da rede cabeada, criar uma segunda infraestrutura de autenticação representaria retrabalho e complicaria as tarefas de administração. Esse é o entendimento que motivou a criação do mecanismo EAP-TTLS. A sigla TTLS significa Tunneled Transport Layer Security (TLS tunelado). O mecanismo funciona em duas etapas. Na primeira, chamada autenticação externa (outer authentication), suplicante e servidor de autenticação estabelecem um túnel TLS. Um certificado é usado para autenticar o servidor RADIUS. Na segunda etapa – autenticação interna (inner authentication) –, um método de autenticação legado é utilizado dentro do túnel TLS,

50

para autenticar o usuário. A vantagem agora é que apenas são necessários certificados para o servidor RADIUS, o que reduz drasticamente a quantidade de certificados a administrar. O Protected EAP (PEAP) é bastante similar ao TTLS. A diferença está na forma como o protocolo interno é operado. No caso do TTLS, o túnel TLS é usado para a troca de pares atributo-valor (Attribute Value Pairs – AVPs) que serão usados pelo mecanismo de autenticação interno. No PEAP, o túnel é usado para iniciar uma segunda transação 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 autenticação interna tem de ser um método EAP.

Métodos de autenticação interna 11 Os métodos de autenticação interna podem ser não criptográficos.

q

22 Operam em um túnel TLS. 11 PAP e MSCHAPv2 são os mais comuns. 22 PAP é um dos métodos pioneiros (usado em enlaces PPP). Login e senha enviados desprotegidos. 22 MSCHAPv2 é a segunda versão do mecanismo criado pela Microsoft. Métodos não criptográficos seriam inseguros se usados sozinhos, mas como mecanismos de autenticação interna, gozam da segurança oferecida pelo canal criptográfico criado pelo túnel TLS. Os dois principais métodos usados com essa finalidade são o PAP e o MSCHAPv2. O MSCHAPv2 (Microsoft CHAP versão 2) está descrito na RFC 2759. É uma atualização do MSCHAPv1, que possuía problemas de segurança. É 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 métodos mais antigos e difundidos. Como dito, é inseguro, já que transmite login e senha sem qualquer autenticação, e por isso deve ser apenas usado como mecanismo interno de autenticação. A seguir, estudaremos detalhes adicionais do PAP e do MSCHAPv2.

Password Authentication Protocol (PAP) 11 O PAP é um protocolo de autenticação simples baseado em senhas.

q

22 O cliente envia login e senha (Auth-Request). 22 O servidor verifica e autentica ou não (Auth-Ack ou Auth Nack).

11 Descrito na RFC 1334 (PPP Authentication Protocols). O Password Authentication Protocol ou Protocolo de Autenticação de Senhas (PAP) é tão simples quanto possível. O cliente inicia a transação através de um quadro Authentication-request, que transporta tanto o login quanto a senha do usuário. O servidor, após a verificação dessas credenciais, responde com um quadro Authentication-ack, caso as credenciais tenham sido aprovadas, ou Authentication-nak, caso contrário. Como dito, o PAP é um mecanismo de autenticação fraco, visto que as informações dos usuários não são protegidas e podem ser facilmente interceptadas por capturadores de pacotes (sniffers). Por isso, recomenda-se seu uso apenas como método de autenticação

Capítulo 3 - Métodos de autenticação

11 Autenticação fraca.

interno, caso em que suas transações são criptografadas pelo túnel TLS. 51

O PAP é um dos dois métodos descritos na RFC 1334 (protocolos de autenticação para enlaces PPP). O outro é o CHAP, no qual o próximo método estudado (MSCHAPv2) foi baseado.

Microsoft Challenge-Handshake Authentication Protocol (MSCHAP) O MSCHAP existe em duas versões (MSCHAPv1 e MSCHAPv2).

q

11 A versão 1 é obsoleta e não mais suportada. 11 A versão 2 também tem vulnerabilidades conhecidas. O MSCHAP é a versão da Microsoft para o protocolo Challenge-Handshake Authentication Protocol (CHAP, também proposto na RFC 1334). Sua primeira versão, MSCHAPv1 (RFC 2433), deixou de ser suportada (desde o Windows Vista). A segunda versão, MSCHAPv2 (RFC 2759), foi introduzida pelo Windows NT 4.0 e permanece corrente. Porém, o MSCHAPv2 tem vulnerabilidades conhecidas (Cryptanalysis of Microsoft’s PPTP Authentication Extensions – http://www.schneier.com/paper-pptpv2.pdf) que permitem descobrir as credenciais do usuário, usando poder computacional presente em computadores domésticos. O MSCHAPv2 provê autenticação mútua, através do envio de desafios (challenges) nos

q

dois sentidos (para o cliente e para o servidor). 11 Servidor envia um desafio (desafio1) e um id de sessão. 11 Cliente envia resposta contendo: 22 Login. 22 Um desafio (desafio2) para o servidor. 22 Resumo criptográfico (desafio1 + desafio2 + id + senha usuário). 11 Servidor verifica a resposta do cliente e envia: 22 Indicador de sucesso ou de falha. 22 Resumo criptográfico (desafio1 + desafio2 + resposta do cliente + senha do usuário). Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

11 Cliente verifica a resposta de autenticação.

52

PAP e MSCHAPv2 – disponibilidade atual Windows

Linux

iOS

Android

MSCHAP v2

Nativo

Nativo

Nativo

Nativo

PAP

Não (SecureW2)

Nativo

Não (MobileConfig)

Nativo

A Tabela 3.1 apresenta a disponibilidade (suporte) aos métodos PAP e MSCHAPv2, em diversos sistemas operacionais populares. Além do Linux e do Windows, são apresentados os sistemas para celulares e tablets, iOS e Android. Nota-se que, enquanto o método MSCHAPv2 é amplamente suportado, o método PAP não é nativo na plataforma Windows e nos iPhones/ iPads. Para o primeiro, é necessário fazer o download de software adicional. Um exemplo é o aplicativo SecureW2 (versão de avaliação disponível em http://www.securew2.com). No caso do iOS, a solução é baixar o MobileConfig, da AppStore. Mas a disponibilidade desses métodos pode mudar rapidamente, com o surgimento e popularização de novos sistemas operacionais.

Tabela 3.1 Suporte aos métodos EAP PAP e MsCHAPv2.

Outros métodos (menos usados) São muitos os métodos de autenticação EAP. No entanto, poucos são realmente populares. Além dos citados até agora, merecem destaque os seguintes métodos: 11 EAP-LEAP: método proprietário da Cisco Systems, consiste de uma versão reforçada do MSCHAP. O fabricante só recomenda seu uso em ambientes onde as senhas sejam cuidadosamente selecionadas (senhas fortes, com mistura de números, letras maiúsculas e minúsculas e caracteres especiais). Não é nativamente suportado pelos sistemas operacionais populares, mas o suporte pode ser instalado. De qualquer maneira, pela reconhecida dificuldade em educar os usuários para que selecionem senhas fortes, o próprio fabricante recomenda outros métodos. 11 EAP-SIM: suporte aos cartões Módulo de Identificação do Assinante (SIM), usados em dispositivos móveis desde a tecnologia celular GSM. O protocolo usado provê autenticação mútua e AAA (Authentication, Authorization and Accounting). O método é não criptográfico. No caso da telefonia celular, fica a cargo de cada operadora proteger a transação da forma que julgar adequada. 11 EAP-MD5: provê segurança mínima, através do uso de resumos criptográficos do tipo MD5 (sujeitos a ataques de dicionário – em que o resumo é comparado a outros resumos de senhas conhecidas). Além disso, não provê autenticação do servidor. 11 EAP-GTC: o Generic Token Card é o token que começa a se popularizar, à medida que são adotados métodos de certificação para o cidadão, como o e-CPF. O método EAP-GTC é baseado em desafio. O token é responsável por criptografar o desafio enviado pelo servidor de autenticação. Tokens também podem suportar senhas descartáveis (one-time passwords), que são usadas apenas uma vez.

Métodos EAP e eduroam 11 No serviço eduroam, cada instituição escolhe seus métodos de autenticação.

q

11 A autenticação é sempre feita na instituição de origem. 11 A autenticação mista é sempre recomendada. 11 Os métodos externos mais usados são o TTLS e o PEAP. 11 Os métodos internos mais usados são o PAP e o MSCHAPv2. MSCHAPv2 parece mais seguro que o PAP (pelo uso de desafios). No entanto, ambos são métodos inseguros e devem ser usados como métodos internos, apenas. No MSCHAPv2, a forma como as senhas são criptografas para armazenamento na base de dados é con-

Atualmente, o MSCHAPv2 é suportado por um número maior de clientes do que o PAP. Para usuários com acesso a informação privilegiada em uma instituição, recomenda-se o uso de TLS, reforçando a autenticação do usuário. Em um sistema de federação, cada instituição participante define de forma autônoma e independente as políticas e tecnologias a serem usadas, contanto que aderentes às especificações básicas impostas pela federação. Uma das vantagens da tecnologia escolhida para o eduroam é a possibilidade de que cada instituição escolha um esquema de autenticação diferente e que, ainda assim, um usuário visitante possa usar a infraestrutura de conectividade local, visto que o pedido de autenticação é tratado pela instituição de origem do visitante. A autenticação mista (com a combinação de um método externo seguro e um interno não tão seguro) é

Capítulo 3 - Métodos de autenticação

siderada vulnerável.

usual e recomendada tanto para TTLS quanto para PEAP e são soluções consideradas seguras. 53

Em relação ao método interno, apesar de o protocolo MSCHAPv2, em um primeiro momento, parecer mais seguro que o PAP, o fato é que ambos os métodos são inseguros e devem ser usados apenas como métodos de autenticação interna. O método MSCHAPv2 é o único método nativo em uma ampla gama de dispositivos como, por exemplo, aqueles executando sistemas operacionais da família Windows, mas o armazenamento de suas senhas (protegidas pelo NT hash) é considerado inseguro. Uma instituição pode optar por oferecer um ou ambos desses métodos ou mesmo recorrer a outros (como o Cartão de Token Genérico – GTC, por exemplo). Além disso, métodos diferentes podem ser usados para usuários diferentes. Pode-se desejar, por exemplo, utilizar um método em que o usuário com privilégios tenha de prover um certificado (como o método TLS). O importante é que as escolhas de uma instituição não afetam o restante da federação e não implicam incompatibilidade.

Atividade Prática 2 e Configurar clientes com diferentes métodos de autenticação Resumo dos dados utilizados nesta atividade prática Usuário para autenticação com suplicantes.

Professor irá fornecer (algo como “teste”).

Senha para autenticação com suplicantes.

Professor irá fornecer (algo como “teste123”).

Combinação de métodos EAP (externo/interno).

TTLS/PAP PEAP/MSCHAPv2

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

Ponto de Acesso

54

Usuário

Servidor RADIUS Instituição 1

A segunda prática tem como objetivo configurar diferentes dispositivos como clientes do serviço eduroam. Serão demonstradas configurações nos sistemas operacionais Windows, Linux e Android. Dependendo do sistema operacional e dos métodos de autenticação utilizados, softwares adicionais podem ser necessários para permitir a configuração do dispositivo cliente.

Configuração de dispositivos para TTLS/PAP Configurações para Android 1. Para conectar-se à rede eduroam utilizando TTLS/PAP, primeiro entre no menu de

Configurações/Settings. 2. No menu de configurações, entre em Conexões sem fio e rede (Figura 3.6a). 3. Uma vez acessada a opção Conexões sem fio e rede, vá para Configurações Wi-Fi (Figura 3.6b)

Figura 3.5 Prática de configuração de clientes para acesso a partir de diversos dispositivos.

4. Nas Configurações Wi-Fi, selecione a rede eduroam (Figura 3.6c).

Figura 3.6 Configuração do cliente Android (a), (b) e (c).

5. Será aberta uma nova janela, assim como na Figura 3.7a. O método EAP de primeira fase

será TTLS, e o de segunda fase, PAP (não selecione certificados ou credenciais). 6. Por fim, insira no campo Identidade seu usuário@domíniodainstituição. No campo Senha,

insira sua senha e deixe o campo Identidade Anônima em branco (Figura 3.7b).

Figura 3.7 Configuração do cliente Android (a) e (b).

Configurações para Windows Para a configuração do cliente Windows, será necessária a utilização de um software de

Siga os passos a seguir para a instalação e configuração do suporte ao TTLS/PAP para Windows. 1. Download do SecureW2 [SecureW2, 2012].

Capítulo 3 - Métodos de autenticação

terceiros (SecureW2), uma vez que o Windows não suporta nativamente o método TTLS.

55

Passos para a instalação do SecureW2 1. Clique em Next e aceite o acordo (Figura 3.8a). 2. Certifique-se de que o componente TTLS está marcado e termine a instalação (Figura 3.8b).

3. Em Iniciar, clique em Painel de Controle/Rede e Internet/Centro de Rede e Compartilhamento.

Clique em Gerenciar Redes Sem Fio. Clique com o botão direito na rede eduroam e em seguida em Propriedades (Figura 3.9a).

Figura 3.8 Instalação do SecureW2 (a) e (b).

4. Na aba Segurança, escolha o Tipo de Segurança como WPA2-Enterprise, e Tipo de Criptografia,

AES. Selecione também, como método de autenticação, o SecureW2 EAP-TTLS e desmarque

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

as demais caixas. Clique em Configurações e siga para o próximo passo (Figura 3.9b).

56

5. Clique em New para criar um novo perfil ou em Configure para editar o perfil Default

(Figura 3.10a). 6. Na aba Certificates, desmarque a caixa Verify Server certificate (Figura 3.10b). 7. Na aba Authentication, selecione o método PAP e clique em OK (Figura 3.10c).

Figura 3.9 Finalização da instalação do SecureW2 (a) e configuração do Windows (b).

Figura 3.10 Configuração do SecureW2 (a), (b) e (c).

8. Na aba User account desmarque a opção Prompt user for credentials, coloque seu nome

de usuário, sua senha e o domínio (e.g. uff.br) (Figura 3.11a). 9. No mesmo menu Tarefas, no Centro de Redes e Compartilhamento, clique em Conectar-se a

uma rede. Clique em eduroam e em seguida em Conectar (Figura 3.11b).

Figura 3.11 Finalização da configuração do SecureW2 (a) e conectando ao eduroam (b).

Configurações para Linux (Ubuntu) O Linux já oferece suporte ao TTLS e PAP de forma nativa, suprimindo a necessidade de

1. Selecione a rede eduroam nas redes sem fio. 2. Configure a rede como wireless security: WPA & WPA2 Enterprise; em Authentication, escolha

Tuneled TLS; já em Inner Authentication, escolha PAP. Nos campos de usuário e senha, utilize seu usuário@instituição.br e a senha equivalente (Figura 3.12a). 3. Caso apareça um alerta de certificado, ignore-o (Figura 3.12b).

Capítulo 3 - Métodos de autenticação

instalação de um software suplicante de terceiros.

57

Figura 3.12 Configuração do Linux para TTLS/ PAP (a) e (b).

Configuração de dispositivos para PEAP/MSCHAPv2 Em geral, os dispositivos sem fio têm suporte nativo aos métodos PEAP e MSCHAPv2, porém, é comum a necessidade de uma configuração adicional para a não verificação dos certificados autoassinados (não validados por uma CA real) no estabelecimento da conexão. Portanto, caso seja utilizado um certificado gerado localmente no servidor RADIUS para estabelecimento das conexões PEAP (e também TTLS), será necessário suprimir a verificação da validade desse certificado.

Configurações para Android 1. Para conectar-se à rede eduroam utilizando PEAP/MSCHAPv2, primeiro entre no menu de

Configurações/Settings. 2. No menu de Configurações, entre em Conexões sem fio e rede (Figura 3.13a). 3. Uma vez acessada a opção Conexões sem fio e rede, vá para Configurações Wi-Fi Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

(Figura 3.13b).

58

4. Nas Configurações Wi-Fi, selecione a rede eduroam (Figura 3.13c).

Figura 3.13 Configuração do cliente Android (a), (b) e (c).

5. Será aberta uma nova janela, assim como na Figura 3.13. O método EAP de primeira fase

será PEAP, e o de segunda fase, MSCHAPv2 (não selecione certificados ou credenciais).

6. Por fim, insira no campo Identidade seu usuário@domíniodainstituição. No campo Senha,

insira sua senha e deixe o campo Identidade Anônima em branco (Figura 3.14).

Figura 3.14 Configuração PEAP/MSCHAv2 para Android.

Configurações para Windows XP 1. Vá ao menu Iniciar/Painel de Controle (Figura 3.15a). 2. Escolha a opção Conexões de Rede (Figura 3.15b).

3. Clique com o botão direito do mouse em cima da conexão de rede sem fio e escolha

a opção Propriedades (Figura 3.16a). 4. Escolha a opção Redes sem fio no menu do lado esquerdo (Figura 3.16b). 5. Escolha a opção Adicionar (Figura 3.16c).

Capítulo 3 - Métodos de autenticação

Figura 3.15 Configuração do PEAP/MSCHAPv2 para Windows XP (a) e (b).

59

6. Digite as informações da rede sem fio para autenticação de rede, como WPA2, e cripto-

grafia, como AES, conforme a Figura 3.17a. 7. Vá até a aba Autenticação (Figura 3.17b).

Figura 3.16 Configuração do Windows XP (a) e adição de uma nova rede (b) e (c).

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

8. Altere o tipo de EAP como na figura a seguir e escolha Propriedades (Figura 3.17c).

60

9. Desmarque a opção Validar certificado do servidor e, em seguida, escolha a opção

Configurar (Figura 3.18a). 10. Desmarque a opção Usar automaticamente meu nome... Em seguida, escolha OK em todas

as telas restantes. 11. Já é possível conectar-se informando seu usuário@instituição.br e senha (Figura 3.18c).

Figura 3.17 Configurando o método de autenticação PEAP/MSCHAv2 para o Windows XP (a), (b) e (c).

Capítulo 3 - Métodos de autenticação

Figura 3.18 Finalizando a configuração do Windows XP, retirando a validação de certificados (a), (b) e (c).

61

62

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

4 Conhecer os conceitos mais importantes de um sistema de autenticação baseado no padrão RADIUS, compreendendo seu papel fundamental para o serviço eduroam. Adquirir conhecimentos básicos sobre a instalação e configuração essencial do RADIUS para operar no contexto do eduroam.

conceitos

Componentes da arquitetura cliente-servidor do RADIUS. NAS, suplicante e servidor de autenticação. O conceito de AAA: Authentication, Authorization and Accounting (Autenticação, Autorização e Contabilização).

Introdução 11 O Remote Authentication Dial in User Services (RADIUS) segue o paradigma

q

cliente-servidor. 11 Os componentes de sua arquitetura são: 22 Cliente RADIUS: envia ao servidor as credenciais do usuário. 22 Servidor RADIUS: verifica essas credenciais. 11 Foi criado primeiramente apenas para autenticação e foi posteriormente estendido para Autorização e Accounting (AAA). O Remote Authentication Dial In User Service (RADIUS) é um padrão IETF que oferece serviço de Autenticação, Autorização e Auditoria (AAA), consolidado no mercado como uma solução robusta para diversos serviços de autenticação. Desenvolvido no início da década 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 métodos mais seguros para controle de acesso às redes sem fio. O RADIUS foi proposto originalmente pela RFC 2058, seguida de diversas revisões (RFCs 2138, 2865). O serviço de accounting foi proposto em RFC separada [RFC 2866]. O RADIUS é utilizado para prover um serviço de autenticação 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. 

Capítulo 4 - RADIUS – Visão geral e conceitos fundamentais

objetivos

RADIUS – Visão geral e conceitos fundamentais

63

O serviço adota o modelo cliente-servidor. O cliente RADIUS é responsável por obter a informação sobre o cliente final e repassá-la para o servidor RADIUS, além de interpretar a resposta, dando ou não acesso ao cliente.

Cliente RADIUS O cliente RADIUS é um intermediário entre o usuário que busca autenticação e o servidor.

q

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 (também usado o termo NAS). O cliente RADIUS é, tipicamente, um intermediário entre o dispositivo do usuário final e o servidor. O tipo de cliente dependerá, portanto, do tipo de rede sendo utilizado. Em redes de acesso remoto, onde o usuário se conecta por intermédio 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 próprio 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 também 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 usuário. As credenciais podem

q

estar armazenadas em: 11 Bancos de dados SQL. 11 Diretórios LDAP. 11 Em um arquivo texto local. O servidor RADIUS é responsável por receber pedidos de conexão, autenticar o usuário Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

e repassar ao cliente RADIUS as informações necessárias para este dar acesso à rede ao

64

usuário. As credenciais do usuário são 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.

Serviços oferecidos pelo RADIUS O RADIUS oferece o serviço AAA: 11 Autenticação (Authentication): verificar a autenticidade de usuários, através da checagem de suas credenciais (login e senha, certificados digitais, biometria etc.). 11 Autorização (Authorization): determinar os privilégios de um usuário autenticado. 11 Contabilidade (Accounting): quantificar e registrar o uso de recursos por parte dos usuários. O RADIUS foi proposto originalmente para autenticação em redes Point-to-Point Protocol (PPP) e posteriormente estendido para oferecer mecanismos de autorização e também accounting. Além disso, também passou a oferecer esse serviço em outros tipos de rede.

q

RADIUS e EAP 802.1X

Figura 4.1 Esquema 802.1X de encaminhamento de autenticação de um cliente até o servidor RADIUS.

Suplicante

EAP sobre L2 (EAPOL)

Autenticador

EAP sob RADIUS

Servidor RADIUS

BD

Em redes locais, o padrão RADIUS pode ser utilizado em conjunto com o padrão Extensible Authentication Protocol (EAP). Como comentado anteriormente, o padrão IEEE 802.1X descreve o encapsulamento do EAP sobre os padrões IEEE 802. Nesse cenário, destacamos os três componentes principais do serviço de autenticação, o cliente final ou suplicante (quando utilizados métodos 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 requisição de autenticação. Na prática, 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 Demonstração da localização 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 móvel do usuário, o NAS é o ponto de acesso (AP) e o servidor RADIUS é um computador acessado pelo AP (NAS) através da rede cabeada.

O NAS exerce papel importante na comunicação entre suplicante e servidor RADIUS:

q

11 Encaminha requisições do suplicante ao RADIUS. 11 É responsável pela coleta de informações para accounting. 11 Utiliza IEEE 802.1X (acesso baseado em portas). Porta Controlada

Suplicante 1 Figura 4.3 Demonstração da porta controlada e não controlada no 802.1X [Nakhjiri, 2005].

Porta não Controlada Autenticador

Suplicante N

servidor RADIUS

Capítulo 4 - RADIUS – Visão geral e conceitos fundamentais

NAS

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 não o acesso à rede. Quando utilizado accounting, o NAS é o responsável por coletar e enviar as informações necessárias ao servidor RADIUS. Utiliza o padrão 802.1X, que realiza o controle de acesso baseado em portas e, como tal, inicialmente recebe e encaminha pacotes por uma porta não controlada. Conforme a resposta do servidor RADIUS, libera uma porta ao cliente (porta controlada) para acesso à rede (e outros serviços, como DHCP) ou não.

Suplicante

q

O suplicante é executado na máquina do usuário: 11 Requisita acesso ao NAS. 11 NAS encaminha pedido ao servidor RADIUS. 11 Deve suportar métodos EAP. 22 PAP, CHAP, MSCHAP, ou seja, suplicantes são os softwares que dão suporte aos métodos EAP.

O suplicante é o componente de software executado no dispositivo do usuário final. É ele que envia os dados do usuário ao NAS, que, por sua vez, os reencaminha ao servidor RADIUS. Assim, o suplicante deve suportar diversos métodos EAP. Os métodos mais utilizados são: PAP, CHAP, MSCHAPv2 etc. Caso seja exigido pelo servidor RADIUS um método não suportado pelo suplicante em questão, o cliente será incapaz de se autenticar.

RADIUS e eduroam

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

eduroam

66

AL

.br

Figura 4.4 Exemplo de demonstração da hierarquia do eduroam mundial ligando América Latina e Europa.

EU

.pe

.pt

.uk

Uma característica importante do RADIUS é permitir a criação de uma estrutura distribuída e hierárquica de autenticação. Essa funcionalidade é o requisito fundamental para a criação de um serviço federado como o eduroam. Voltaremos ao tema da montagem de uma federação com RADIUS e ao serviço de roaming no Capítulo 6.

O protocolo RADIUS O protocolo RADIUS é transportado sobre UDP. Portas utilizadas: 11 1812 para autenticação 11 1813 para contabilização.

q

Alguns servidores usam as portas não padronizadas 1654 e 1646 (respectivamente). Para comunicação 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 usuários são protegidas por uma senha compartilhada entre o autenticador (NAS) e o servidor RADIUS. O restante da mensagem, no entanto, é enviado em texto plano.

Essa solução não oferece grau elevado de segurança e, em muitos casos, recomenda-se a adoção de mecanismos adicionais (como proteção da comunicação através de IPSec) ou do uso da versão criptográfica do protocolo RADIUS, chamada RadSec, que será assunto do Capítulo 7.

Formato da mensagem RADIUS 0

7 Code

15 Identifier

31 Length

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 versões utilizaram a porta 1645, mas as implementações mais populares, como FreeRADIUS e Radiator utilizam a porta oficial 1812.  O formato dos dados enviados pelo protocolo RADIUS segue o formato da mensagem

Tipos de mensagens RADIUS Os tipos são identificados pelo campo Code (1 octeto):

q

11 1 Access-Request: gerado pelo NAS para encaminhamento da requisição do usuário. 11 2 Access-Accept: enviado do RADIUS ao NAS para liberação de porta (acesso). 11 3 Access-Reject: enviado ao NAS como rejeição de autenticação ou autorização. 11 4 e 5 Accounting-Request/Response: tratados na seção 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 estão funcionando. O campo Code é formado por um byte e identifica o tipo da mensagem RADIUS. Caso não possua uma identificação conhecida, ocorre o descarte silencioso da mensagem. Utiliza código 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 códigos.

Capítulo 4 - RADIUS – Visão geral e conceitos fundamentais

descrito a seguir, sendo que os campos são enviados na ordem da direita para a esquerda.

67

Cliente RADIUS

Servidor RADIUS RADIUS: Access-Request (1)

RADIUS: Access-Accept (2)

RADIUS: Access-Reject (3)

RADIUS: Access-Challenge (11)

ou

ou

Outros campos das mensagens RADIUS 11 Identifier (1 octeto): auxilia nos pedidos e respostas do servidor RADIUS. Identifica men-

Figura 4.6 Troca de mensagens RADIUS.

q

sagens duplicadas (mesmo IP, porta de origem e ID em um curto período 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

Figura 4.7 Formato dos campos de atributo.

Valor

Além dos campos identifier (identificador), length (comprimento) e authenticator (autenticador), merecem destaque os campos de atributos, que podem ser vários. Conforme a Figura 4.7, cada atributo possui os campos tipo tamanho e valor. Os atributos transportam as infor-

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

mações de autenticação, como nome de usuário e credenciais, além de outras informações

68

úteis, como a identificação do NAS e da porta a qual o usuário 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 usuário a ser autenticado. Enviado, geralmente, no pacote Access-Request. 11 2 User-Password: atributo referente à senha do usuário a ser autenticado. Enviado no pacote Access-Request. 11 3 CHAP-Password: esse atributo indica uma resposta do usuário ao handshake de desafio do CHAP. Enviado no pacote Access-Request quando utilizado esse método EAP. 11 4 NAS-IP-Address: esse atributo indica o IP do NAS que requisitou a autenticação do usuário. 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 “física” por onde o usuário está se autenticando. 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.

q

11 6 Service-Type: esse atributo informa o serviço requisitado ou provido pelo servidor

q

RADIUS ao NAS. Por exemplo, um atributo com o campo Administrative informará ao NAS que o usuário tem permissão 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. Porém, devemos ressaltar que geralmente o NAS-IP-Address é o mais utilizado como esse identificador e não tal atributo. 11 33 Proxy-State: é o atributo que diz que aquele pacote RADIUS foi redirecionado entre proxies (Access-Request). Cada servidor intermediário insere seu atributo Proxy-State e o retira quando volta a resposta (Access-Accept, Access-Reject ou Access-Challenge).

Exemplo (parte 1)

q

11 Usuário “nemo” deseja acesso. 11 Senha compartilhada (NAS - Servidor): “xyzzy5461”. 11 Senha do usuário: “arctangent”. 11 Acesso realizado pela porta 3. 11 Será enviado um pacote UDP com um pedido de acesso (Access-Request).

Como exemplo, considere a solicitação do usuário “nemo” para acesso em uma determinada rede. Os dados referentes à identificação do usuário, senha compartilhada, senha de usuário e porta são informados na mensagem RADIUS, que será encapsulada em um pacote UDP.

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

Code=Access-Request ID = 0 Length = 56 Request Authentication: número randômico 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 NAS 192.168.1.16

Servidor RADIUS A mensagem RADIUS é formada com os campos necessários e as informações do usuário. A senha é completada com zeros até formar um múltiplo de dezesseis bytes. Em seguida, o Request Authenticator é concatenado a ela e depois é calculado o hash por MD5. Esse valor, então, entra em um XOR com os dezesseis primeiros octetos da senha e são guardados nos dezesseis primeiros octetos da string do campo de senha do usuário. 

Capítulo 4 - RADIUS – Visão geral e conceitos fundamentais

Figura 4.8 Conteúdo de uma mensagem Access-Request.

69

Caso a senha possua mais do que dezesseis caracteres, o hash é recalculado com a concatenação da senha com o resultado do primeiro XOR. Em seguida, esse novo resultado entra em um XOR com os próximos 16 octetos da senha e o resultado final é guardado no segundo campo de 16 octetos do campo de string do atributo. Essa operação será repetida quantas vezes forem necessárias, até o máximo 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 Servidor RADIUS

NAS 192.168.1.16 Já a mensagem de sucesso enviada em resposta ao pedido de autenticação do cliente é

Figura 4.9 Conteúdo de uma mensagem de retorno do tipo Access-Accept.

formada principalmente pelo código da resposta, o ID e um checksum carregado no Response Authenticator. Com isso, o NAS libera a porta 3 ao cliente para o acesso.

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

Comandos do FreeRADIUS Comandos mais comuns: 11 radiusd ou freeradiusd (daemon). 11 radtest (teste de autenticação). 11 radiusd –X (modo debug).

radtest -t mschap usuário senha_do_usuario endereço_servidor_Radius:porta_Radius porta NAS senha_compartilhada

Exemplo: ratest –t mschap teste teste123 localhost:1812 0 eduroam123 70

q

Os principais comandos utilizados normalmente por um administrador FreeRADIUS são: freeradius, radiusd e radtest.

Atividade Prática 3 e Instalação e configuração de um servidor RADIUS Resumo dos dados utilizados nesta atividade prática Usuário de teste criado no arquivo “users”

clientex (exatamente como escrito, não substitua o “x”)

Senha do usuário de teste

password

Senha compartilhada entre o localhost e o RADIUS

eduroam123

Arquivos editados Arquivo para liberação do localhost como NAS

/etc/freeradius/clientes.conf

Arquivo contendo o cadastro do usuário

/etc/freeradius/users

Arquivo de configuração do métodos EAP externo

/etc/freeradius/eap.conf /etc/freeradius/sites-enabled/inner-tunnel (padrão)

Arquivo de configuração dos métodos EAP internos

Ou se você seguiu o tutorial e criou um arquivo novo, chamado “eduroam” /etc/freeradius/sites-enabled/eduroam

A terceira prática tem como objetivo realizar a instalação e configuração de um servidor RADIUS representando uma instituição de ensino e pesquisa e configurar um ponto de acesso para encaminhar os pedidos de autenticação a esse servidor, tal como ilustrado na Figura 4.10.

Figura 4.10 Prática de instalação do servidor RADIUS de uma instituição.

Usuário

Servidor RADIUS Instituição 1

Instalando o RADIUS Para implementar o serviço RADIUS, utilizaremos nesta prática o software FreeRADIUS. A instalação do servidor é bem simples e demanda poucos comandos.

# sudo apt-get install freeradius

Configurando o RADIUS sem federação Primeiramente será configurado um servidor RADIUS capaz de autenticar usuários 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 autenticação em localhost e em texto plano. O referido arquivo deverá

Capítulo 4 - RADIUS – Visão geral e conceitos fundamentais

Ponto de Acesso

conter as seguintes linhas: 71

# Bloco referente ao endereço 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 autenticação junto com AccessRequest, porém clientes mais antigos não a enviam. Em nosso caso não exigimos mensagem de autenticação vinda do cliente

require_message_authenticator = no

# Nome dado ao cliente

shortname

= localhost

# Opcional, usados para verificar a possibilidade de conexões simultâneas pelo mesmo cliente. Localhost não usa NAS. nastype



= other

} No arquivo /etc/freeradius/users, deveremos acrescentar as linhas:

# Composto por nome do usuário, tipo de password armazenado (texto puro) e uma mensagem de retorno ao cliente caso o usuário 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:

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

# freeradius -X

72

Agora, vamos testar a autenticação do usuário. Para isso, vamos executar o autenticador de teste (radtest) para o usuário criado com sua respectiva senha, apontando para o servidor FreeRADIUS na porta padrão (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 são 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 conexão foi realizada com sucesso é algo como a destacada a seguir:

# Enviando a mensagem de requisição 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”

NAS-IP-Address = 127.0.0.1 NAS-Port = 0 # Retorno do servidor RADIUS ao cliente # Sucesso na autenticação 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 autenticação de clientes em uma base local com senha em texto plano, seguiremos para uma segunda etapa. Antes de utilizar o LDAP para consulta de usuários, vamos à configuração dos métodos de autenticação, EAP. Primeiramente deveremos configurar o arquivo /etc/freeradius/eap.conf contendo as seguintes informações:

# Bloco de configuração para os métodos EAP suportados eap {

# Alteramos o método default de PEAP para TTLS # TTLS (EAP TLS tunelado), pode utilizar apenas de certificados do lado do servidor. Ou seja, TTLS como EAP e método de segunda fase sendo PAP, CHAP, MSCHAPv2 etc, ou ainda TLS (certificado também do lado do cliente) se não houver método de segunda fase.

#default_eap_type = peap



default_eap_type = ttls

# Tempo em que se mantém uma determinada resposta a um EAP-Request

timer_expire = 60

poderíamos 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

Capítulo 4 - RADIUS – Visão geral e conceitos fundamentais

# Ignorar tipos de EAP não conhecidos? Por padrão, não, mas

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 {

# Método EAP de segunda fase padrão

default_eap_type = mschapv2

# Qualquer mensagem trocada que não estaria dentro do túnel é copiada para ele

copy_request_to_tunnel = yes

# Respostas ao NAS serão dadas com base nos atributos internos ao túnel. Exemplo: responde ao NAS com o usuário verdade e não anonymous.

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada



74

use_tunneled_reply = yes

# Passado o arquivo de configuração para os métodos de autorização, autenticação, 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.



mschapv2 {



}

} Tanto para a utilização de TTLS ou PEAP é referenciado o arquivo /etc/freeradius/sites-enable/eduroam como virtual_server, e é nele que deveremos configurar os métodos de autenticação suportados.

Atenção neste ponto: se você utilizar o arquivo padrão citado pelo FreeRADIUS, teremos a edição e indicação no eap.conf para o arquivo chamado inner-tunnel e não 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 excluímos o inner-tunnel nela existente.

Vamos configurar o arquivo /etc/freeradius/sites-enable/eduroam. É relevante citar que as informações não constantes no arquivo mencionado serão pesquisadas no arquivo /etc/freeradius/sites-enable/default, que como o próprio nome sugere, contém as configurações padrão do aplicativo.

server eduroam {

# Métodos suportados para autorização

authorize { suffix

auth_log



files



#

ldap



mschap



pap

eap { ok = return

}



}

# métodos suporados para autenticação. Onde buscar? Com que padrão?

authenticate {

# Manter comentado até a próxima prática, onde habilitaremos o LDAP

Capítulo 4 - RADIUS – Visão geral e conceitos fundamentais

# Manter comentado até a próxima prática, onde habilitaremos o LDAP

75

#



Auth-Type LDAP{

#



#

ldap



}



Auth-Type PAP{

pap



}



Auth-Type MS-CHAP{



mschap

} eap



}



preacct {



}



accounting {

detail radutmp

unix



Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada



attr_filter.accounting_response



}



session { radutmp



}



post-auth {

Post-Auth-Type REJECT {



76

reply_log

}

reply_log }



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 configurações necessárias à terceira prática, precisamos configurar o servidor RADIUS para aceitar requisições de um ponto de acesso específico e também configurar esse ponto de acesso para enviar pedidos de autenticação de usuários ao servidor RADIUS. Esse procedimento é idêntico ao já realizado na primeira atividade prática, por isso sugerimos que o leitor consulte o final do Capítulo 2. Com isso, encerra-se a etapa de configurações propostas neste capítulo. Através delas, é possível realizar autenticação e autorização, por intermédio de um servidor RADIUS, onde cada usuário pode acessar a infraestrutura de rede sem fio utilizando seu login e senha

Capítulo 4 - RADIUS – Visão geral e conceitos fundamentais

cadastrados na base de usuários do servidor RADIUS.

77

78

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

5 Conhecer os conceitos básicos de um diretório LDAP. Adquirir conhecimentos básicos sobre a instalação e configuração de um servidor LDAP para operar no contexto do eduroam.

conceitos

Serviço de diretório. Estrutura e modelo de um diretório LDAP. Classes de objetos, árvores e esquemas. O esquema brEduPerson.

Introdução 11 Um diretório é uma base de dados especializada.

q

22 Otimizada para busca e navegação. 22 Grande volume de informação textual. 33 Pessoas, instituições, serviços etc. 22 Escrita e atualização são esporádicas, porém suportadas. 22 Pode ser local ou distribuído. Um diretório é uma base de dados que contém dados descritivos sobre entidades, pessoas, grupos, instituições e serviços. Como base de dados, se distingue pelo grande volume de dados armazenados de forma a facilitar a busca e navegação, ou seja, trata-se de um sistema otimizado para leitura. As operações de escrita e atualização são menos comuns, porém são também suportadas. Um diretório é, portanto, diferente de um Sistema de Bancos de Dados (SGBD) Relacional, como o PostgreSQL. Um diretório pode ser local, consistindo em informação concentrada em uma única localidade (servidor) ou distribuído entre vários servidores. Um exemplo recorrente de base de dados distribuído é o sistema de nomes usado na Internet (Domain Name System – DNS), onde uma hierarquia de servidores mantém partes de uma base de dados global (os nomes de domínios, como www.rnp.br ou mail.empresa.com.br). Entretanto, o DNS não é navegável (browsable) e não suporta buscas e, por isso, apesar de ser uma base de dados distribuída, não consiste propriamente de um diretório. Um exemplo de diretório é o Open Directory Project (http://www.dmoz.org/), uma base de dados de links para páginas na web, organizadas em uma hierarquia, pesquisável e navegável.

Capítulo 5 - LDAP – Visão geral e conceitos fundamentais

objetivos

LDAP – Visão geral e conceitos fundamentais

79

Surgimento do LDAP 11 X.500.

q

22 Conjunto de padrões do UIT para sistemas de diretórios. 22 Surgiu nos anos 1980. 11 DAP – Directory Access Protocol. 22 Ou X.500 Directory Access Protocol. Era o protocolo de acesso a um diretório 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 versão 3. As empresas de telecomunicações estiveram entre as primeiras a identificar a necessidade de um sistema de diretórios eficiente e escalável, para armazenar listas telefônicas que permitissem localização rápida. Com o avanço da digitalização dos sistemas de telefonia, nos anos 80, a União Internacional de Telecomunicações (UIT) especificou o padrão X.500, consistindo em um sistema de diretórios X.500 e seu respectivo protocolo de acesso, o X.500 Directory Access Protocol ou DAP. Esse protocolo foi concebido para operação 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 começava gradualmente a substituir as redes OSI ao longo dos anos 80 e 90. O LDAP é um padrão do IETF especificado na RFC 4510.

Versões do LDAP 11 LDAPv3.

q

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

22 Final dos anos 90.

80

22 Autenticação forte com SASL. 33 Suporte a certificados TLS e SSL. 22 Internacionalização – Unicode. 22 Encaminhamentos (Referrals). 11 LDAPv2 é considerado ultrapassado. 22 Ainda é suportado (OpenLDAP, desabilitado por default). 22 Incompatível com o LDAPv3. A versão 3 do LDAP foi desenvolvida no final dos anos 90 em substituição à versão 2 e oferecia as seguintes novas funcionalidades, entre outras: Autenticação forte com SASL – O LDAPv2 suportava três métodos de autenticação: anônimo (ou seja, sem autenticação), login e senha (em texto plano) e Kerberos (um mecanismo de autenticação cliente/servidor). O LDAPv3 introduziu o Simple Authentication and Security Layer (SASL) que, além de suportar os mecanismos anteriores, passou a permitir outros métodos de autenticação (como o TLS, por exemplo), de forma modular.

Internacionalização: o LDAPv3 passou a dar suporte ao conjunto de caracteres Unicode, a evolução do padrão ISO 10646. Encaminhamentos: um encaminhamento (referral) é uma informação enviada pelo servidor de volta ao cliente, indicando que a informação solicitada pode ser obtida de outra fonte. No LDAPv2, os encaminhamentos não eram suportados nativamente, sendo incorporados de forma improvisada e não padronizada em mensagens de erro (a mensagem de “resposta parcial”). Na versão 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. Além disso, LDAPv2 e o LDAPv3 são incompatíveis e sua implementação concorrente é considerada difícil e problemática.

Operação do LDAP 11 O LDAP segue o modelo cliente-servidor.

q

22 Cliente se conecta a um servidor e envia sua requisição. 22 Servidor responde e/ou envia ponteiro para outro servidor. 11 Consistência na visão do cliente. 22 Mesmo resultado independente do servidor consultado. O LDAP é um protocolo de aplicação que utiliza o modelo cliente-servidor. Um ou mais servidores contêm os dados que perfazem a árvore de informações do diretório (Directory Information Tree – DIT). O cliente se conecta ao servidor, envia sua requisição e pode enviar várias requisições ainda que não 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 visão de um diretório.

Cliente e Servidor LDAP Cliente LDAP:

q

11 Disponível para os principais sistemas operacionais. Servidor LDAP:

11 Utiliza TCP como protocolo de transporte. 11 Opera, por padrão, na porta 389. Existem clientes LDAP disponíveis para os principais sistemas operacionais utilizados atualmente. Alguns exemplos são o Active Directory Explorer, para Windows; o Evolution, para Linux, e o Address Book, nativo do MacOS X. Existem também clientes multiplataforma, que funcionam baseados na web, como o FusionDirectory, o phpLDAPadmin e o JXplorer, entre outros. Há também uma grande variedade de implementações de servidores LDAP (também chamado de Directory System Agent – DSA), tanto de grandes fabricantes (IBM Tivoli Directory Server, Oracle Internet Directory, Apple Open Directory, entre outros), como distribuídos como software livre, como o OpenLDAP, sobre o qual nossos exemplos serão construídos.

Capítulo 5 - LDAP – Visão geral e conceitos fundamentais

11 Muitas vezes chamado Directory System Agent (DSA).

81

Protocolo LDAP

q

Transportado sobre TCP (porta padrão 389). As opções de requisições do cliente LDAP são: 11 StartTLS: iniciar uma sessão TLS para criptografar a conexão. 11 Bind: autenticar e especificar a versão do protocolo LDAP a ser usada. 11 Search: realizar uma busca no diretório. 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 requisição. 11 Unbind: encerrar a conexão. O cliente se comunica com os servidores através de requisições enviadas com o protocolo

LDAP. O protocolo LDAP utiliza o transporte confiável oferecido pelo TCP e o servidor LDAP escuta, por padrão, a porta 389. A principal requisição é a de busca, “search”, mas existem também as requisições que permitem editar o conteúdo da base (como Add, Delete e Modify). As requisições Bind e Unbind são usadas para iniciar e encerrar conexões LDAP. O cliente pode enviar várias requisições, mesmo sem ter recebido respostas, e o servidor pode respondê-las em qualquer ordem.

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

Organização e estruturas do LDAP

82

c = GB

Figura 5.1 Exemplo da visualização de uma árvore de diretórios LDAP (a) e (b).

c = US

dc = net

dc = com

dc=DE

st = California

The Organisation

The Organisation o = Acme

dc = example

ou = Marketing

Organisation Unit

ou = Servers

Organisation Unit ou = People

ou = Sales

Person cn = Barbara Jenson

Person uid = babs

A unidade básica de informação no LDAP é a entrada (entry). As entradas são arranjadas de forma hierárquica através de uma estrutura em árvore, chamada Directory Information Tree (DIT). Conforme podemos ver na Figura 5.1a, as entradas referentes aos países aparecem no topo da hierarquia, seguidas pelos estados e organizações, por sua vez povoadas por unidades, pessoas, dispositivos, documentos etc. Outra forma de organização da árvore LDAP, e que tem sido popularizada, é baseada nos nomes de domínios da internet e está representada na Figura 5.1b. Essa abordagem ajuda a localização de diretórios através do serviço de DNS.

Modelos LDAP São quatro os modelos básicos definidos pelo LDAP (em conjunto, eles descrevem

q

completamente a operação do diretório): 11 Modelo de Informação: define o tipo de informação que pode ser armazenada. 11 Modelo de Nomes: define como a informação pode ser organizada e referenciada. 11 Modelo Funcional: descreve as operações que podem ser realizadas nos dados. 11 Modelo de Segurança: recomenda os mecanismos de autenticação e controle de acesso a serem usados. Considerando os objetivos deste livro, abordaremos mais detalhadamente apenas o Modelo de Informação.

Modelo de Informação do LDAP 11 Entradas são os contêineres de dados da estrutura hierárquica.

q

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 instância de um ou mais objectClasses. 11 Cada objectClass tem um nome e pode conter atributos. 11 Cada atributo tem um nome e usualmente contém dados. 11 Os dados são, portanto, armazenados como atributos.

quica de objetos, chamados “entradas” (entries). A árvore resultante é chamada de Directory Information Tree (DIT). O topo da hierarquia é chamado de raiz (root), base ou sufixo. Cada entrada na árvore contém uma entrada pai e zero ou mais entradas filho (objetos). Cada entrada é uma instância de uma ou mais classes de objetos (objectClasses) e possui um nome único. As objectClasses contêm zero ou mais atributos e definem os atributos obrigatórios e opcionais. Os atributos possuem nomes e podem também possuir apelidos (aliases) e abreviações. Os dados de interesse do LDAP estão armazenados sob a forma de atributos.

Tipos de classe de objeto 11 objectClasses podem ser de três tipos: 22 Abstratas: modelo para criação de outras classes. 22 Estruturais: classes instanciadas pelas entradas. 22 Auxiliares: também instanciadas pelas entradas, mas apenas para estender as classes estruturais.

q

Capítulo 5 - LDAP – Visão geral e conceitos fundamentais

Como dissemos, em um diretório LDAP os dados são representados em uma estrutura hierár-

83

11 A definição de que classes são abstratas, estruturais ou auxiliares é definida por um

q

esquema (estudado adiante). Uma classe de objetos pode ser declarada como classe abstrata, estrutural ou auxiliar. Classes de objetos abstratas são usadas como modelo para criação de outras classes e as entradas do diretório não podem ser instâncias de classes de objeto abstratas. Entradas do diretório são sempre instâncias de classes de objetos estruturais. Uma classe auxiliar serve para estender uma classe estrutural e não pode ser a única a instanciar uma entrada do diretório. Uma entrada de diretório deve instanciar ao menos uma classe estrutural.

Directory Information Tree DIT

root objectClass = name entry

Filho

Pai

objectClass-name-value attribute-name-value attribute-name-value ... attribute-name-value [defined using ASN.1] objectClass = name

entry

entry

Irmão

Irmão

objectClass-name-value attribute-name-value attribute-name-value ... attribute-name-value

Figura 5.2 Exemplo de DIT e seus objectClasses.

[defined using ASN.1] A Figura 5.2 ilustra uma Directory Information Tree (DIT) bastante simplificada. Nota-se que Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

uma determinada entrada (entry) é instância de diversas objectClasses que possuem, cada

84

uma, diversos atributos. Uma entrada pode possuir parents, childs e siblings (entradas de nível superior, inferior ou mesmo nível na hierarquia).

Descrição da árvore e das entradas – LDIF 11 LDIF = LDAP Data Interchange Format. 11 Descrição textual da árvore hierárquica.

dn: uid=jsliva, dc=uff, dc=br sn: Silva cn: Jose uid: jsilva objectClass: person objectClass: inetOrgPerson objectClass: sambaSamAccount

q

userPassword: {SSHA}gWRX6IuyiGw+0xvPN3JhaGEcvuLJqmlB sambaNTPassword: 1E39A9A92F2B08A0E69B4D5ADA7E5332 LDIF (Data Interchange Format – LDAP) descreve textualmente trechos da árvore hierárquica (DIT) e contém valores de cada atributo de cada entrada. Note que um servidor contém uma subárvore da árvore global do LDAP (por exemplo, todas as entradas sob o domínio “uff.br”) e que, nesse caso, essa subárvore estará definida em um arquivo LDIF. O exemplo mostra um trecho de um arquivo LDIF, referente à entrada do usuário jsilva associado à instituição uff.br ( José Silva, no caso): 11 “dn” é o nome único (distinguished name) da entrada. 11 “dc”s são componentes do nome de domínio (domain component). Nesse caso, do domínio “.uff.br”. O objeto no exemplo é instância de três objectClasses: person, inetOrgPerson e sambaSamAccount. Essas classes (em conjunto) definem uma coleção de atributos para a entrada: 11 “cn” e “sn” designam, respectivamente o nome e sobrenome. 11 “uid” o user id do usuário. 11 “sambaNTPassword” a senha do usuário em formato suportado pelo MSCHAPv2. 11 “userPassword” a senha do usuário em formato suportado pelo PAP.

Esquemas LDAP 11 Um esquema LDAP consiste em um pacote contendo objectClasses e atributos.

q

11 Forma prática de encapsular atributos e classes que traduzem o interesse específico de uma instituição. 11 Todos os atributos e objectClasses, incluindo os atributos e objectClasses superiores na hierarquia. 11 Esquemas são configurados no servidor LDAP. Um esquema LDAP define as regras e a sintaxe, assim como a lista de objectClasses, seus classes de interesse específico de uma instituição, ou seja, diferentes instituições podem 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 federação Comunidade Acadêmica Federada (CAFe), comentado a seguir.

Esquema brEduPerson 11 Objetiva armazenar dados de pessoas ligadas às instituições de ensino superior no Brasil. 22 Professores, funcionários, alunos e pesquisadores. 22 Suporta múltiplos vínculos com a instituição. 11 Informações de residentes no Brasil e informações especificamente ligadas à comunidade acadêmica.

q

Capítulo 5 - LDAP – Visão geral e conceitos fundamentais

tipos e atributos de uma subárvore. O esquema facilita o empacotamento dos atributos e

85

O esquema brEduPerson foi criado para permitir o armazenamento dos dados de pessoas ligadas às instituições de ensino superior no Brasil e seus (possivelmente múltiplos) vínculos. Esse esquema armazena informações específicas para a realidade brasileira, tais como informações genéricas sobre residentes no país (como o CPF) e dados específicos sobre os membros de uma instituição (email, cargo, matrícula, data de ingresso etc.). O brEduPerson pode ser utilizado de forma integrada com outros esquemas LDAP que também descrevem informações 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:

q

22 inetOrgPerson (estrutural). 22 schacPersonalCharacteristics, eduPerson e brPerson (auxiliares). 11 inetOrgPerson – pessoas (RFC 2798). 11 schacPersonalCharacteristics – extensões ao inetOrgPerson. 22 Sugeridas pela Terena. 11 eduPerson – pessoas ligadas à comunidade acadêmica. 22 Criado no âmbito da Internet2. 11 brPerson – dados de um brasileiro ou residente no país. 22 CPF e passaporte. No brEduPerson, a entrada principal de cada usuário é 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 específicos de pessoas que vivem no Brasil,

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

como CPF e número 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 Implementação de código 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 Utilitários, ferramentas e amostras de configurações e clientes. 11 Exemplos: ldapadd e ldapsearch. O OpenLDAP (http://www.openldap.org) é uma implementação de código aberto do LDAP para o sistema operacional Linux. Além do servidor (slapd = Standalone LDAP Daemon), a distribuição inclui as bibliotecas que implementam o protocolo LDAP e uma série de

86

q

utilitários, como ldapadd, que permite adicionar entradas à base de dados no formato LDIF, e ldasearch, que permite a realização de buscas no diretório.

OpenLDAP: iniciando e parando o servidor 11 Iniciando...

q

/usr/local/libexec/slapd []* 11 Exemplos de opções:

-f arquivo (arquivo de configuração alternativo) -d nível (nível de debug) 11 Parando... kill -INT `cat /usr/local/var/slapd.pid´

A localização do slapd e do “pid file” é determinada na instalação e pode variar.

Para iniciar o servidor, basta evocar diretamente o executável slapd, cuja localização default é /usr/local/libexec (configurável durante a instalação). O daemon aceita opções como “–f”, para informar um arquivo de configuração alternativo (a localização default do arquivo de configuração é /usr/local/etc/openldap/slapd.conf ), ou -d

Saiba mais

l

Para mais detalhes sobre essas opções acesse o site do OpenLDAP: http://www.openldap. org/doc/admin24/ runningslapd. html#Command-Line%20Options

para configurar o nível 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 localização default (também configurável na instalação) é /usr/local/var/slapd.pid. Portanto, para interromper o servidor, basta digitar:

kill -INT `cat /usr/local/var/slapd.pid´

Resumo dos dados utilizados nesta atividade prática Domínio utilizado

rnpteste.br O que corresponde à DIT: dc=rnpteste,dc=br

Usuário de teste criado

teste

Senha do usuário de teste

senha1

Senha compartilhada entre Localhost e FreeRADIUS

eduroam123

Usuário de administração do LDAP

admin

Senha do usuário de administração do LDAP

Criada por você no momento do dkpg-reconfigure

Capítulo 5 - LDAP – Visão geral e conceitos fundamentais

Atividade Prática 4 e Instalação e configuração de um servidor LDAP

87

Arquivos editados Arquivo pivot de suporte MSCHAPv2

/tmp/schema_convert.conf

Arquivo de importação do suporte MSCHAPv2

/tmp/ldif_output/cn\=config/cn\=schema/cn\=\{13\}samba.ldif

Arquivo de modulo do LDAP no FreeRADIUS

/etc/freeradius/modules/ldap

Arquivo de habilitação do módulo LDAP no FreeRADIUS

/etc/freeradius/sites-enable/inner-tunnel (padrão) Ou se você seguiu o tutorial e criou um arquivo novo chamado “eduroam” /etc/freeradius/sites-enable/eduroam

Arquivo de inserção do usuário no LDAP

user.ldif

Ponto de Acesso

Servidor RADIUS Instituição 1

Usuário

Servidor LDAP Instituição 1

A quarta atividade prática tem como objetivo realizar a instalação e configuração de um servidor LDAP representando a base de usuários de uma instituição de ensino e pesquisa. Será feita também a configuração do serviço RADIUS para consulta das credenciais de um usuário na base LDAP. Primeiro vamos instalar o OpenLDAP no servidor:

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

# apt-get install slapd ldap-utils

88

Você será questionado sobre a senha do administrador do OpenLDAP. Ao final deste processo, você verá as linhas de inicialização do OpenLDAP:

Creating new user openldap... done. Creating initial configuration... done. Creating LDAP directory... done. Starting OpenLDAP: slapd.

Configurações básicas A configuração padrão, apenas para constar, caso não utilizássemos a interface de configuração mais à frente, seria:

# cat /usr/share/doc/slapd/examples/slapd.conf include

/etc/ldap/schema/core.schema

include

/etc/ldap/schema/cosine.schema

Figura 5.3 Prática de configuração do servidor LDAP.

include

/etc/ldap/schema/nis.schema

include

/etc/ldap/schema/inetorgperson.schema

pidfile

/var/run/slapd/slapd.pid

argsfile

/var/run/slapd/slapd.args

loglevel

none

modulepath

/usr/lib/ldap

moduleload

back_@BACKEND@

sizelimit 500 tool-threads 1 backend

@BACKEND@

database

@BACKEND@

suffix

“@SUFFIX@”

directory

“/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

objectClass eq

lastmod

on

checkpoint

512 30

access to attrs=userPassword,shadowLastChange

by anonymous auth by self write by * none access to dn.base=”” by * read access to * by dn=”@ADMIN@” write by * read Por padrão, o OpenLDAP executa com uma base mínima. Como não queremos que a base OpenLDAP criada esteja diretamente vinculada ao domínio configurado na instalação do nosso servidor, executamos o comando de reconfiguração da base:

# dpkg-reconfigure slapd

Capítulo 5 - LDAP – Visão geral e conceitos fundamentais

by dn=”@ADMIN@” write

89

E você poderá editar todos os principais detalhes do seu servidor OpenLDAP. Uma observação, no nosso exemplo o domínio utilizado, foi: rnpteste.br, então 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=

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

structuralObjectClass: organizationalRole Essa é a base mínima para o domínio rnpteste.br, com isso, podemos inicializar o uso básico do OpenLDAP.

Adicionando o schema do Samba no OpenLDAP Se você precisar utilizar usuários com hashes NT/LM, será necessário inserir o schema do Samba. Esse esquema é necessário para oferecer o método de autenticação MSCHAPv2.

# apt-get install samba-doc O arquivo samba.schema.gz, que queremos, vai estar em /usr/share/doc/samba-doc/examples/LDAP/. Agora precisamos convertê-lo para o novo padrão 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 conversão:

# 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 diretório de saída para a configuração:

# mkdir /tmp/ldif_output E agora vamos usar o comando slaptest para converter os schemas:

# cd /tmp # slaptest -f schema_convert.conf -F /tmp/ldif_output/ config file testing succeeded Ele vai gerar vários arquivos .ldif dentro 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 informações desnecessárias. Ao abrir o arquivo, você vai ver algo como:

dn: cn={13}samba

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

Capítulo 5 - LDAP – Visão geral e conceitos fundamentais

objectClass: olcSchemaConfig

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 padrão 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 configuração 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 o OpenLDAP em um servidor, devemos configurar o FreeRADIUS para autenticar no OpenLDAP. É necessário adicionar o suporte ao LDAP pelo FreeRADIUS, e isso é simples com o seguinte comando:

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

apt-get install freeradius-ldap

92

Vamos editar o módulo do OpenLDAP 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

tls { start_tls = no } dictionary_mapping = ${confdir}/ldap.attrmap edir_account_policy_check = no set_auth_type = no } Feito isso, a comunicação do FreeRADIUS com o OpenLDAP está configurada. O próximo passo é ativar o LDAP como método de autenticação nos sites, editando o arquivo default:

# vim /etc/freeradius/sites-enabled/default authorize { ... ldap ... }

authenticate { ... Auth-Type LDAP { ldap } ...

A priori, o que interessa é que, em authorize, você tire o comentário da linha que contém o LDAP e, em authenticate, a parte que fala sobre o tipo de autenticação LDAP. Faça o mesmo no arquivo eduroam:

# vim /etc/freeradius/sites-enabled/eduroam authorize { ... ldap ... }

Capítulo 5 - LDAP – Visão geral e conceitos fundamentais

}

authenticate { 93

... Auth-Type LDAP { ldap } ... } Deixe as outras configurações como estão (não precisa alterá-las). Vamos agora testar para verificar se o funcionamento é conforme o esperado.

Criando um usuário para testes Vamos adicionar um usuário 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

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

sambaNTPassword: 1E39A9A92F2B08A0E69B4D5ADA7E5332

94

sambaSID: 1 A senha desse usuário é “senha1”. Vamos adicioná-lo na base do OpenLDAP:

# ldapadd -x –W -D “cn=admin,dc=rnpteste,dc=br” -f user.ldif Se o usuário 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 autenticação com as credenciais desse usuário.

# radtest -t mschap teste senha1 localhost:1812 0 eduroam123 Onde teste é o nosso usuário 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

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

Capítulo 5 - LDAP – Visão geral e conceitos fundamentais

O usuário foi autenticado corretamente.

95

96

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

6 Compreender o conceito de roaming e a importância de um sistema hierárquico de autenticação para viabilizar a mobilidade de usuários entre instituições. Adquirir conhecimentos básicos sobre a configuração de servidores de autenticação federados.

conceitos

Federação hierárquica para autenticação com RADIUS. Domínios (realms) e servidores de encaminhamento (proxy RADIUS).

Introdução 11 Finalidade do roaming:

q

22 Prover acesso transparente a usuários em instituições parceiras independentes. 22 Manter identidade única. 22 Métodos de autenticação são selecionados na instituição de origem. 22 Integrar o serviço RADIUS geograficamente. 11 Premissa básica do eduroam. O roaming desempenha a principal função do serviço eduroam (education roaming), que é integrar e tornar transparente ao usuário da comunidade acadêmica o acesso à rede em uma instituição parceira visitada. O roaming facilita o acesso do usuário pelo fato de permitir que seja utilizada apenas uma única identidade, aquela criada em sua instituição de origem. Todas essas funcionalidades se devem também ao fato de que o método de autenticação do usuário não será alterado em momento algum durante o encaminhamento dos pacotes RADIUS, preservando, assim, os métodos EAP selecionados por sua instituição de origem (PAP, MSCHAPv2 etc.).

Capítulo 6 - Roaming no eduroam: conceitos e funcionamento

objetivos

Roaming no eduroam: conceitos e funcionamento

97

Estrutura hierárquica 3° Nível Confederação

2° Nível Federação

.br

.ar Figura 6.1 Exemplo de hierarquia de servidores eduroam em nível continental.

1° Nível Institucional UFRJ

UFMS

UFF

Como já foi estudado, o eduroam utiliza estrutura hierárquica de três níveis de servidores de autenticação, onde o primeiro nível compreende as instituições participantes. No segundo nível, há o ponto central do país (representando a federação), ao qual a instituição é subordinada. Finalmente, no terceiro nível dessa hierarquia, está o servidor da confederação, que é aquele que interliga todos os servidores das federações participantes. A estrutura hierárquica de servidores é configurada estaticamente pelos administradores do serviço, através da edição de arquivos de configuração dos servidores RADIUS.

Realms (domínio) 11 Identificação da instituição de origem.

q

11 Definido por um delimitador @.

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

22 Outro delimitador seria o \ (exemplo: domínio Windows).

98

Para que o acesso seja transparente ao usuário em roaming, configure sempre login@dominio. Os realms (domínios) identificam qual a instituição de origem do usuário. É a partir dessa informação que o servidor RADIUS saberá como encontrar a instituição originária do usuário. Pode-se fazer um paralelo, nesse momento, com a hierarquia DNS. Por conta da forma como o RADIUS funciona, é recomendável que sempre ao configurar o dispositivo o usuário utilize seu login informando o domínio correspondente à sua instituição. Isso porque, caso não seja indicado nenhum domínio, o servidor RADIUS da instituição visitada tentará autenticar aquele usuário localmente, isto é, como se o usuário fosse da própria instituição. Nesse caso, o acesso do usuário em uma instituição visitada não será transparente, pois sua requisição de acesso não será enviada à sua instituição de origem. Para conseguir o acesso à rede na instituição visitada, seria necessário reconfigurar suas credenciais, informando o domínio que representa sua instituição de origem.

Infraestrutura do provedor de acesso 2° Nível Federação

Federação Proxy RADIUS

instituto.br

1° Nível Institucional

universidade.br

Instituição A: Servidor RADIUS

Instituição B: Servidor RADIUS

Ponto de Acesso

Servidor LDAP

Servidor LDAP

Figura 6.2 Exemplo de infraestrutura eduroam com duas instituições distintas.

Processo de autenticação local 2° Nível Federação

Federação Proxy RADIUS

[email protected] senha universidade.br Instituição A: Servidor RADIUS

Ponto de Acesso Figura 6.3 Exemplo de um processo de autenticação de um usuário local.

Instituição B: Servidor RADIUS

Servidor LDAP

Servidor LDAP

A Figura 6.2 ilustra um exemplo de infraestrutura de servidores RADIUS e LDAP, representando duas instituições distintas que oferecem o serviço eduroam. Para permitir a mobilidade de usuários entre essas instituições, é necessária a comunicação entre os servidores RADIUS de cada instituição e o servidor RADIUS da federação. A Figura 6.3 ilustra o mesmo cenário, considerando um pedido de acesso local de um usuário da Universidade Federal Fluminense (UFF) (exemplo: [email protected]). Nesse caso, o pedido de autenticação para acesso desse usuário será tratado localmente pelo servidor RADIUS de sua instituição (UFF, no exemplo).

Capítulo 6 - Roaming no eduroam: conceitos e funcionamento

1° Nível Institucional

99

Processo de Autenticação Remota

2° Nível Federação

Federação Proxy RADIUS

[email protected] senha

[email protected] senha

1° Nível Institucional

universidade.br Instituição A: Servidor RADIUS

Ponto de Acesso

Instituição B: Servidor RADIUS

Servidor LDAP

Servidor LDAP

A Figura 6.4 apresenta outro exemplo que ilustra a mobilidade de usuários entre institui-

Figura 6.4 Exemplo de autenticação de usuário em roaming.

ções, onde a funcionalidade de roaming é utilizada. No exemplo, um usuário da Universidade Federal do Rio de Janeiro (UFRJ) (exemplo: [email protected]) visita a Universidade Federal Fluminense (UFF). O pedido de autenticação desse usuário será recebido pelo servidor RADIUS da instituição visitada (UFF), que por sua vez, ao verificar que o domínio relacionado ao usuário não corresponde ao domínio local, encaminhará a solicitação ao servidor de nível acima (federação). Uma vez encontrada a instituição de origem do usuário (UFRJ, no exemplo), a requisição é então encaminhada ao seu servidor RADIUS, que realiza a verificação necessária e retorna a resposta pelo caminho contrário.

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

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 Não é removido no caminho de ida, mas podem ser acrescentados mais atributos Proxy-State. O papel do servidor RADIUS de uma instituição visitada (servidor de encaminhamento ou

proxy) é intermediar a transação que se dará entre o autenticador local (o ponto de acesso na instituição visitada) e o servidor RADIUS da instituição 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 instituição de origem do usuário é identificada pelo seu domínio. Quando um servidor RADIUS recebe uma solicitação de

100

q

l É possível utilizar uma identificação externa (outer tunnel – fora do túnel) diferente da original (por exemplo, anonymous@dominio_ real), mantendo a identificação correta (usuario_real@dominio_ real), a ser realmente consultada no servidor de origem do usuário, apenas dentro do túnel (inner-tunnel). Essa forma é bem difundida na comunidade eduroam e visa ocultar a identificação real do usuário em roaming, uma vez que o servidor de encaminhamento necessita apenas do domínio para realizar o encaminhamento da mensagem.

requisição e a encaminha ao servidor RADIUS de próximo nível, seguindo a hierarquia de servidores pré-configurada. Todos os servidores intermediários, ao encaminharem mensagens 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 próprio suplicante.

Atividade Prática 5 e Configuração de proxy para a federação (roaming) Resumo dos dados utilizados nesta atividade prática Usuário de teste

Qualquer um criado anteriormente, tanto o do arquivo de texto quando o do LDAP

Senha do usuário de teste

As respectivas

Senha compartilhada entre o servidor RADIUS da instituição (aluno) e o RADIUS da federação (professor)

Usualmente: eduroam123

Arquivos editados Configuração do proxy, responsável por todo redirecionamento da instituição para a federação

/etc/freeradius/proxy.conf

Liberação da comunicação com o servidor da federação

/etc/freeradius/clients.conf

Servidor RADIUS Federação

UDP Ponto de Acesso

Usuário

Figura 6.5 Destaque do servidor a ser configurado durante a atividade prática.

UDP

Servidor RADIUS Instituição 2 Servidor RADIUS Instituição 1

Servidor RADIUS Instituição 2

Servidor LDAP Instituição 1

A quinta atividade prática tem como objetivo configurar um servidor RADIUS representando uma instituição de ensino e pesquisa para que esta ofereça o serviço de roaming. Essa prática mostrará também as configurações necessárias no servidor da federação eduroam, representando um determinado país, para que uma nova instituição faça parte dessa federação e ofereça o serviço de roaming. A configuração do proxy do servidor RADIUS da instituição se faz necessária para o encaminhamento de requisições de autenticação por usuários não pertencentes ao domínio local. Sendo assim, será avaliado pelo proxy RADIUS da instituição se o domínio do usuário é local ou se a requisição deve ser encaminhando ao servidor da federação eduroam, que por sua vez a encaminhará à instituição de origem do usuário.

Capítulo 6 - Roaming no eduroam: conceitos e funcionamento

Saiba mais

autenticação para um usuário que não é local, ele insere o atributo Proxy-State nesta

101

Será necessária a configuração do arquivo proxy.conf localizado no diretório /etc/freeradius/ contendo no mínimo a configuração a seguir:

proxy server { default_fallback

= no

}

home_server eduroam-br { type



= auth+acct

ipaddr

= IP_SERVIDOR_FEDERACAO

port

= 1812

secret

= CHAVE_COMPARTILHADA

require_message_authenticator = yes response_window

= 20

zombie_period

= 40

revive_interval

= 120

status_check

= status-server

check_interval

= 30

num_answers_to_alive

= 3

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

coa {

102

irt = 2 mrt = 16 mrc = 5 mrd = 30 } }

home_server_pool EDUROAM-FTLR { # Garantir disponibilidade

type

= fail-over

home_server

= eduroam-br

}

realm DEFAULT { auth_pool



= EDUROAM-FTLR acct_pool

= EDUROAM-FTLR

nostrip } realm LOCAL { }

realm NULL { secret

= CHAVE_COMPARTILHADA

}

realm uff.br { } Basicamente, a configuração compreenderá o seu domínio local, em nosso caso representado por realm uff.br, onde os parâmetros de accthost e authhost correspondem, respectivamente, ao endereço do servidor de accounting e ao servidor de autenticação. Atente para o fato de que, caso a consulta seja local, fica subentendida a realização do strip (por meio do parâmetro que nada mais é que a separação da identificação do usuário de seu domínio. Por exemplo, considere que recebemos [email protected]. Será realizada a separação deste usuário “teste” de seu domínio uff.br para verificação de realm e de usuário na base de dados utilizada. A configuração do realm “DEFAULT” é uma das mais importantes. É nessa seção que serão criados o pool EDUROAM-FTLR, responsável pelo encaminhamento ao servidor da federação. A opção “nostrip” é necessária porque queremos que o login completo do usuário chegue ao servidor da federação, para que seja possível realizar a comparação de realms e verificar para onde será encaminhada sua requisição. Em “EDUROAM-FTLR” é apontada a configuração para o servidor da federação, no caso, eduroam-br. Foi criado esse pool para que seja possível cadastrar mais de um servidor da federação, para que oferecer redundância (fail-over). O home_server eduroam-br expõe as configurações propriamente ditas para a comunicação do servidor da instituição com a federação. Substitua realm uff.br pelo domínio de sua instituição. Observação: é importante ficar atento à chave compartilhada e se o IP do servidor de sua instituição está cadastrado no clients.conf da federação, assim como o IP do servidor da

Capítulo 6 - Roaming no eduroam: conceitos e funcionamento

suffix, que deverá estar habilitado em seu arquivo de virtual_server – Arquivo inner_tunnel),

federação no clients.conf de sua instituição. 103

Adicione o IP do servidor RADIUS da federação em seu clients.conf.

Configurando o proxy da federação Esta configuração será realizada apenas no servidor da federação, ou seja, somente o professor deverá executar a configuração a seguir, a fim de criar a estrutura de federação internamente ao laboratório. Conteúdo do arquivo clients.conf.

# localhost client localhost { ipaddr

= 127.0.0.1

secret

= SENHA_COMPARTILHADA

require_message_authenticator = no nastype

= other

}

# Instituicao XX client 200.20.0.XX/24 { secret

= SENHA_COMPARTILHADA

shortname

= eduroam-uff

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

}

104

# Instituição YY client 200.129.192.YY { secret

= SENHA_COMPARTILHADA

shortname

= UFMS

}

# CONFEDERACAO LATLR client 200.37.WW.UU {

}

secret

= SENHA_COMPARTILHADA_FEDERACAO

shortname

= LATLR

Conteúdo do arquivo proxy.conf.

proxy server { default_fallback

= no

}

# 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

mrd = 30 } }

home_server_pool LATLR { type = fail-over home_server = eduroam-la }

Capítulo 6 - Roaming no eduroam: conceitos e funcionamento

mrc = 5

realm DEFAULT { 105

auth_pool = LATLR acct_pool = LATLR nostrip }

realm LOCAL { }

realm NULL { secret = SENHA_COMPARTILHADA_FEDERACAO }

#INSTITUICOES # UFF realm uff.br { authhost

= 200.20.0.XX:1812

accthost

= 200.20.0.XX:1813

secret

= SENHA_COMPARTILHADA

nostrip

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

}

106

# UFRJ realm ufrj.br { authhost

= 200.129.192.YY:1812

accthost

= 200.129.192.YY:1813

secret

= SENHA_COMPARTILHADA

nostrip }

Teste de roaming Realize testes de autenticação de seu usuário utilizando um ponto de acesso de outra instituição, ou utilize o radtest diretamente do seu servidor informando um usuário de outra instituição.

7 Compreender a importância do uso de criptografia na comunicação entre os componentes da arquitetura RADIUS. Adquirir conhecimentos básicos sobre a instalação e configuração essencial do RadSec e entender suas limitações.

conceitos

RadSec e radsecproxy. Criptografia e comunicação segura com TLS.

Introdução 11 RadSec (RADIUS-over-TLS):

q

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 comunicação RADIUS baseada em UDP para TCP/TLS. 11 Benefícios do RadSec: 22 Segurança (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 padrão. A sua principal premissa é alterar a comunicação baseada no protocolo UDP, utilizada tradicionalmente pelos servidores RADIUS, para uma comunicação baseada em TCP e protegida pelo protocolo criptográfico TLS. Seus principais benefícios em relação à utilização do UDP são o aumento da segurança e da confiabilidade na comunicação entre o autenticador e o servidor de autenticação, ou entre os servidores de autenticação, no caso de um sistema de autenticação hierárquico, como o do eduroam. Este é considerado mais crítico, já que a comunicação entre servidores RADIUS de instituições distintas implica o tráfego dos dados de autenticação em redes administradas por entidades diversas.

Capítulo 7 - RadSec: Segurança na comunicação RADIUS

objetivos

RadSec: Segurança na comunicação RADIUS

107

Deficiências na segurança do RADIUS 11 O padrão RADIUS não é tão seguro.

q

11 No RADIUS, os pares são reconhecidos através de seu IP e do conhecimento de senhas compartilhadas, usadas em conjunto com um resumo criptográfico (hash) MD5. 22 O MD5 é fraco. 22 Alguns atributos são transmitidos em texto-puro. 11 Solução em duas partes: 11 Entre autenticador e servidor: utilizar EAP–TLS, EAP-TTLS ou EAP-PEAP. 11 Entre servidores (esquema de proxy): utilizar o RadSec. O padrão RADIUS apresenta algumas deficiências em sua segurança. Em primeiro lugar, a autenticação de servidores e de clientes RADIUS (autenticadores) é baseada nos endereços IP desses elementos e em senhas pré-compartilhadas (segredos), configuradas nesses dispositivos. As senhas não são usadas diretamente, mas utilizadas para o cálculo de resumos criptográficos gerados pelo algoritmo MD5. Ocorre que, como veremos, o MD5

l

é um algoritmo fraco.

Saiba mais

Além disso, mesmo esse esquema falho é usado apenas para proteger partes da comunicação

Existem ainda outras deficiências no padrão RADIUS. Para conhecer mais sobre os possíveis ataques ao RADIUS: http://www.untruth. org/~josh/security/ radius/radius-auth.html

RADIUS (como senhas de usuários, por exemplo), sendo o restante da mensagem transmitido sem qualquer proteção. Como solução, é indicado que, primeiramente, sejam utilizados métodos EAP seguros durante o encaminhamento das mensagens entre cliente (autenticador) e servidor RADIUS, como o EAP-TTLS, EAP-TLS ou EAP-PEAP. Além disso, para proteger o tráfego entre os servidores de uma federação como a do eduroam, sugere-se a adoção do RadSec.

Vulnerabilidades do MD5 O resumo criptográfico MD5 possui vulnerabilidades publicadas.

q

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

11 Colisão: é possível encontrar duas mensagens M1 e M2, que produzem o mesmo

108

resumo criptográfico (hash). 11 Colisão com prefixo determinado: é possível acrescentar conteúdo ao final de uma mensagem M1, de forma a gerar o mesmo resumo da mensagem M2. Já são bem conhecidos os problemas de segurança do resumo criptográfico MD5. Com computadores já ultrapassados (Pentium 4) é possível encontrar colisões de uma mensagem em poucos segundos. Além disso, são também conhecidos ataques de colisão com prefixo determinado, onde o atacante acrescenta conteúdo ao final de uma mensagem de forma a gerar o mesmo resumo criptográfico de outra mensagem.

Vantagens do RadSec 11 TLS entre as comunicações RADIUS.

q

11 O método obrigatório de autenticação entre os servidores é o uso de Certificados X.509. 11 Cada servidor RADIUS tem seu certificado. 11 Alto nível de criptografia. 22 Criptografa toda a mensagem. 11 Utiliza TCP e não mais UDP. 22 Transporte confiável. 22 Porta 2083. No padrão RadSec, o método obrigatório de autenticação é o uso de certificados X.509, que permitem a criação de uma comunicação segura e mutuamente autenticada. Opcionalmente, podem ser implementadas autenticações com fingerprints dos certificados ou com senhas pré-compartilhadas. Considera-se esse modelo de segurança forte, uma vez que provê alto nível de criptografia. Todo o conteúdo da mensagem é criptografado antes de ser enviado ao servidor RADIUS de destino, e vice-versa. Outra vantagem diz respeito à utilização do TCP em vez do UDP. Um dos primeiros ganhos é a confiabilidade na transmissão 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 conexões e se comunicar com

q

servidores legados (RADIUS-UDP). As mensagens enviadas pelo RadSec são as mesmas do protocolo RADIUS. 11 Access-Request, Accounting-Request etc. O RadSec foi proposto como um perfil de comunicação a ser utilizado por servidores RADIUS. Por isso, um servidor que utiliza RadSec deve ainda ser capaz de operar da forma tradicional, não criptográfica, utilizando o protocolo UDP, como o RADIUS tradicional. Além disso, o conteúdo das mensagens enviadas no protocolo RADIUS não é alterado Accounting-Request etc).

Capítulo 7 - RadSec: Segurança na comunicação RADIUS

pelo RadSec. Isso significa que as mensagens possuem os mesmos tipos (Access-Request,

109

Autenticação com RadSec Federação: RadSec Proxy

1

Figura 7.1 Processo de autenticação com RadSec para um usuário em roaming.

2° Nível Federação 1° Nível Institucional

instituto.br

universidade.br RadSec Proxy

RadSec Proxy RADIUS

Ponto de Acesso

2

2° Nível Federação 1° Nível Institucional

[email protected] senha

RADIUS

Servidor LDAP Federação: RadSec Proxy

instituto.br

universidade.br RadSec Proxy

RadSec Proxy

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

RADIUS

110

Ponto de Acesso

3

[email protected] senha

Servidor LDAP

RADIUS

Servidor LDAP

Servidor LDAP

Federação: RadSec Proxy

2° Nível Federação 1° Nível Institucional

instituto.br

universidade.br RadSec Proxy

RadSec Proxy RADIUS

Ponto de Acesso

Servidor LDAP

RADIUS

Servidor LDAP

4

Estabelecimento de sessão TLS sobre TCP

Federação: RadSec Proxy

2° Nível Federação 1° Nível Institucional

instituto.br RadSec Proxy

Ponto de Acesso

universidade.br

RADIUS

RadSec Proxy

Servidor LDAP

RADIUS

Servidor LDAP

5 Ca113kfsndvasdcsdkbm

Federação: RadSec Proxy

2° Nível Federação instituto.br RadSec Proxy

Ponto de Acesso

6

universidade.br

RADIUS

RadSec Proxy

Servidor LDAP Federação: RadSec Proxy

RADIUS

Servidor LDAP

[email protected] senha

2° Nível Federação 1° Nível Institucional

instituto.br RadSec Proxy

Ponto de Acesso

universidade.br RadSec Proxy RADIUS

Servidor LDAP

RADIUS

Servidor LDAP

Capítulo 7 - RadSec: Segurança na comunicação RADIUS

1° Nível Institucional

111

A Figura 7.1 ilustra um pedido de autenticação de um usuário em roaming enviado com o uso do RadSec para comunicação segura entre o servidor da instituição visitada (UFRJ, no exemplo) e o servidor da federação e, ainda, entre o servidor da federação e o servidor da instituição de origem (UFF, no exemplo), através de conexões TCP/TLS. Observem que o uso de RadSec é indicado para aumentar o nível de segurança na comunicação entre servidores eduroam, entretanto, não é obrigatório. Como a troca de mensagens ocorre entre o servidor da federação e o servidor de cada instituição, em uma mesma federação, algumas instituições podem utilizar RADIUS e outras podem utilizar o RadSec.

Implementações

q

11 Radiator: 11 Implementação comercial do RADIUS. 11 radsecproxy: 22 Implementação gratuita. 22 Pode ser usado em conjunto com o FreeRADIUS.

Atualmente há duas implementações do RADIUS sobre TLS. A primeira implementação, chamada Radiator, é bastante difundida, porém é paga. Já a outra solução, o radsecproxy, é a mais utilizada atualmente no âmbito do eduroam, por ser gratuita e compatível com o FreeRADIUS.

O radsecproxy 11 FreeRADIUS pretende incorporar o padrão RadSec futuramente.

q

11 As configurações são feitas no arquivo radsecproxy.conf. O radsecproxy é uma solução de segurança para ser usada em conjunto com outros servidores RADIUS, como o FreeRADIUS. No radsecproxy, tanto as configurações de certificados, como os clientes autorizados e servidores proxy, ficam em um único arquivo chamado

112

O desenvolvedor do FreeRADIUS, Alan Dekok, já manifestou a intenção de incorporar o padrão RadSec ao servidor, eliminando a necessidade de instalação de software adicional, como o radsecproxy. Funcionamento do radsecproxy:

UDP

TC Ra P/ dS TL ec S

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

radsecproxy.conf.

UDP

Figura 7.2 Comunicação interna do FreeRADIUS (UDP) e o encaminhamento pelo RadSec (TCP/TLS).

Além da função de proxy, como no padrão 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 máquina local), o RadSec funciona com UDP, mas só envia e recebe mensagens remotamente com TCP/TLS.

Comandos do radsecproxy

q

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 são 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 inicialização (start), paralização (stop) e reinicialização (restart). Quando há um erro de sintaxe no arquivo de configuração radsecproxy.conf, a mensagem de erro é genérica e não indica onde o problema ocorreu.

T Ra CP/ dS TL ec S -

RADIUS Resumo dos dados utilizados nesta atividade prática Federação

STL P/ c TC dSe Ra

Atividade Prática 6 e Configuração do proxy com RadSec Servidor

Ponto de Acesso

Usuário Figura 7.3 Ilustração da prática de configuração do RadSec.

Servidor RADIUS Instituição 2 Servidor RADIUS Instituição 1

Servidor RADIUS Instituição 2

Servidor LDAP Instituição 1

A sexta atividade prática tem como objetivo instalar o protocolo RadSec e configurar o

Capítulo 7 - RadSec: Segurança na comunicação RADIUS

Servidor RADIUS Federação

STL P/ c TC dSe Ra

T Ra CP/ dS TL ec S -

Arquivos editados Ponto de Servidor Servidor Acesso RADIUS Configuração geral do proxy RadSec. Neste arquivo são liberados os RADIUS 2 Instituição 2 clientes, criadas as entradas para os domínios, além de configuradas Instituição /etc/radsecproxy.conf as portas e os certificados. Servidor Servidor LDAP RADIUS Liberação da comunicação RadSec com o1 FreeRADIUS local. 1 /etc/freeradius/clients.conf Instituição Instituição Usuário Redirecionamento entre FreeRADIUS e RadSec. /etc/freeradius/proxy.conf

servidor RADIUS de uma instituição e o servidor RADIUS da federação para habilitar a 113

comunicação segura entre eles utilizando o RadSec. Três arquivos são importantes: 11 Certificado da AC (ca.crt). 11 Certificado do servidor da instituição e sua senha associada (instituicao.crt). 11 Chave do certificado (instituicao.key).

Instalação do RadSec em cada instituição Em distribuições baseadas em apt-get, como é o caso do Ubuntu, que utilizamos para instalação do servidor RADIUS, é necessário apenas realizar o download e instalação do radsecproxy pelo comando a seguir.

apt-get install radsecproxy

Configuração do RadSec Após a instalação do pacote, vamos realizar a sua configuração. Por padrão o arquivo de configuração é único e fica em /etc/radsecproxy.conf. Para o servidor de uma instituição, ele deverá ter o conteúdo 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)

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

# Recebe mensagem do radsecproxy da Federacao atraves de TLS

114

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

# Arquivo de log LogDestination

file:///var/log/radsecproxy.log

# Configuracao de certificado tls default { CACertificateFile

/etc/freeradius/certs/instituicoes/ca.crt

CertificateFile

/etc/freeradius/certs/instituicoes/uff.crt

CertificateKeyFile

/etc/freeradius/certs/instituicoes/uff.key

certificateKeyPassword SENHA_DO_CERTIFICADO }

# Excluindo TAG de VLAN rewrite defaultclient { removeAttribute

64

removeAttribute

65

removeAttribute

81

}

# Autenticacao na instituicao local # Recebe as conexoes TLS vindas do radsecproxy da Federacao... client 200.20.10.88 {

type tls secret Senha_Compartilhada_Federação certificateNameCheck off }

# ... e repassa para o radius da propria maquina (local) server 127.0.0.1 { host historico.uff.br type udp

Capítulo 7 - RadSec: Segurança na comunicação RADIUS

host 200.20.10.88

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_Federação StatusServer on

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

}

116

# 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 }

realm * { server 200.20.10.88 accountingServer 200.20.10.88 }

Instalação do certificado Como pode ser visto no conteúdo do arquivo radsecproxy.conf, é necessário ter os certificados instalados no servidor para que a comunicação segura via TLS seja estabelecida. Sendo assim, é necessário salvar o certificado da instituição e a chave do certificado da instituição, assim como o certificado da AC (Autoridade Certificadora) da federação em uma subpasta (no exemplo do arquivo radseproxy.conf, essa pasta se chama instituicoes e fica em /etc/freeradius/certs/ ). Outro passo necessário para que a AC que gerou o certificado seja confiável 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 Após abrir a tela de seleção de certificados de AC confiáveis, o arquivo ca.crt, que foi adicionado, deve ser marcado. Assim serão atualizados todos os índices e a AC da federação, que gerou o certificado da instituição, será considerada como confiável.

Configuração do FreeRADIUS É necessário uma simples e pontual mudança no arquivo proxy.conf do FreeRADIUS, como indicado a seguir.

…

type ipaddr

= auth+acct = 127.0.0.1

#ipaddr

= 200.20.10.88

#port

= 1812

port

= 1830

... A linha que realiza o encaminhamento direto para o servidor da federação (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,

Capítulo 7 - RadSec: Segurança na comunicação RADIUS

home_server eduroam-br {

117

disponíveis no arquivo /var/log/radsecproxy.log. Para iniciar o RadSec, o seguinte comando deve ser utilizado.

/etc/init.d/radsecproxy start

Geração de certificados Os certificados, que serão utilizados com o protocolo RadSec, podem ser gerados pelo servidor da federação. Para isso, é necessária a criação de uma Autoridade Certificadora (AC). Este passo será realizado somente pelo professor em um sua máquina e se encontra exposto somente como guia de referência. Para a criação de uma AC, é necessária a instalação do OpenSSL no servidor da federação.

apt-get install openssl Em seguida, é necessário criar uma base de dados para a AC.

cd /etc/freeradius/certs/ echo 01 > serial touch index.txt O próximo passo é configurar o arquivo de geração da AC. Esse arquivo será também utilizado no momento da assinatura dos certificados das instituições. Podemos visualizar o conteúdo desse arquivo a seguir.

[ ca ] default_ca

= CA_default

[ CA_default ]

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

dir

118

= ./

serial

= $dir/serial

database

= $dir/index.txt

new_certs_dir

= $dir

certificate

= $dir/ca.crt

private_key

= $dir/ca.key

default_days

= 365

default_md

= md5

preserve

= no

email_in_dn

= no

nameopt

= default_ca

certopt

= default_ca

policy

= policy_anything

[ policy_match ] countryName

= match

stateOrProvinceName

= match

organizationName

= match

organizationalUnitName

= optional

commonName

= supplied

emailAddress

= optional

[ policy_anything ] countryName

= optional

stateOrProvinceName

= optional

localityName

= optional

organizationName

= optional

organizationalUnitName

= optional

commonName

= supplied

emailAddress

= optional

prompt

= no

distinguished_name

= certificate_authority

default_bits

= 2048

input_password

= SENHA_DO_CERTIFICADO

output_password

= SENHA_DO_CERTIFICADO

#x509_extensions

= v3_ca

x509_extensions

= v3_req

[ req_distinguished_name ] # Variable name #-------------------------

Prompt string ----------------------------------

0.organizationName

= UFF

organizationalUnitName

= Midiacom

emailAddress

= [email protected]

Capítulo 7 - RadSec: Segurança na comunicação RADIUS

[ req ]

119

emailAddress_max

= 40

localityName

= Niteroi

stateOrProvinceName

= Rio de Janeiro

countryName

= BR

countryName_min

= 2

countryName_max

= 2

commonName

= moreninha.midiacom.uff.br

commonName_max

= 64

# Default values for the above, for consistency and less typing. # Variable name

Value

#------------------------

------------------------------

0.organizationName_default

= UFF

localityName_default

= Niteroi

stateOrProvinceName_default

= Rio de Janeiro

countryName_default

= BR

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

[certificate_authority] countryName

= BR

stateOrProvinceName

= RJ

localityName

= Niteroi

organizationName

= UFF

emailAddress

= [email protected]

commonName

= IP ou nome da máquina do Professor

[v3_ca] subjectKeyIdentifier

= hash

authorityKeyIdentifier

= keyid:always,issuer:always

basicConstraints

= CA:true

extendedKeyUsage

= serverAuth, clientAuth

[ v3_req ] basicConstraints = CA:FALSE subjectKeyIdentifier = hash

120

extendedKeyUsage

= serverAuth, clientAuth

Como convenção, a partir deste momento, usaremos o conteúdo da Tabela 7.1 para a nomenclatura das extensões dos arquivos criados durante o processo de geração de certificados. Definição

.cnf

Arquivo de configuração do certificado.

.csr

Requisição de geração de certificado.

.key

Chave do certificado.

.crt

Certificado.

Vamos agora criar o certificado raiz de nossa AC. Atenção 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 (instituição – exemplo: UFF).

[ ca ] default_ca

= CA_default

[ CA_default ] dir

= ./

certs

= $dir

crl_dir

= $dir/crl

database

= $dir/index.txt

new_certs_dir

= $dir

certificate

= $dir/server.pem

serial

= $dir/serial

crl

= $dir/crl.pem

private_key

= $dir/server.key

RANDFILE

= $dir/.rand

name_opt

= ca_default

cert_opt

= ca_default

default_days

= 1825

default_crl_days

= 30

default_md

= md5

preserve

= no

Capítulo 7 - RadSec: Segurança na comunicação RADIUS

Tabela 7.1 Extensões de arquivos.

Extensão

121

policy

= policy_match

[ policy_match ] countryName

= match

stateOrProvinceName

= match

organizationName

= match

organizationalUnitName

= optional

commonName

= supplied

emailAddress

= optional

[ policy_anything ] countryName

= optional

stateOrProvinceName

= optional

localityName

= optional

organizationName

= optional

organizationalUnitName

= optional

commonName

= supplied

emailAddress

= optional

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

[ req ]

122

prompt

= no

distinguished_name

= uff

default_bits

= 2048

input_password

= SENHA_DO_CERTIFICADO

output_password

= SENHA_DO_CERTIFICADO

x509_extensions

= v3_ca

[uff] countryName

= BR

stateOrProvinceName

= RJ

localityName

= Niteroi

organizationName

= Nome da Instituição

emailAddress

= [email protected]

commonName

= IP da máquina da instituição ou FQDN

[v3_ca] subjectKeyIdentifier

= hash

authorityKeyIdentifier

= keyid:always,issuer:always

basicConstraints

= CA:true

extendedKeyUsage

= serverAuth, clientAuth

Em seguida, é necessário gerar o certificado da instituição 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 à instituição correspondente.

Configuração do servidor da federação O conteúdo do arquivo proxy.conf do servidor da federação é ilustrado a seguir.

proxy server { default_fallback

= no

}

# LATLR home_server eduroam-la {

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

Capítulo 7 - RadSec: Segurança na comunicação RADIUS

type = auth+acct

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

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

}

realm LOCAL { }

realm NULL { secret = SENHA_COMPARTILHADA_FEDERACAO }

#INSTITUICOES # UFF realm uff.br { authhost secret nostrip

124

= 127.0.0.1:1830 = SENHA_COMPARTILHADA

}

# UFRJ Realm ufrj.br { authhost

= 127.0.0.1:1830

secret

= SENHA_COMPARTILHADA

nostrip } Vamos então às configurações de entradas para o arquivo radsecproxy.conf, referente ao RadSec. É nesse arquivo que realmente serão inseridas as entradas para os domínios e a confederação, assim como a liberação das requisições vindas dos clientes (servidores das instituições e confederação).

# 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)

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

Capítulo 7 - RadSec: Segurança na comunicação RADIUS

## Recebe as mensagens do radius local na porta 1830

On 125

# # Configuracao de certificado tls default { CACertificateFile

/etc/freeradius/certs/ca.crt

CertificateFile

/etc/freeradius/certs/federacao.crt

CertificateKeyFile

/etc/freeradius/certs/federacao.key

certificateKeyPassword SENHA_CERTIFICADO }

# Remove TAG da VLAN rewrite defaultclient { removeAttribute

64

removeAttribute

65

removeAttribute

81

}

# Recebe as conexoes TLS vindas dos radsecproxies institucionais # Cliente UFF

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

client 200.20.0.XX {

126

host

eduroam.uff.br

type

TLS

secret

SENHA_COMPARTILHADA

certificateNameCheck off }

client 127.0.0.1 { host

127.0.0.1

type

UDP

secret

SENHA_COMPARTILHADA

}

# ... e repassa para o radius da instituicao destino

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 confederação, para aqueles não conhecidos. realm uff.br { server uff.br }

realm * { server LATLR }

Capítulo 7 - RadSec: Segurança na comunicação RADIUS

}

127

128

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

8 Compreender a finalidade e operação básica de um sistema de contabilização (accounting) de acesso baseado no padrão RADIUS. Adquirir conhecimentos básicos sobre a instalação e configuração do sistema de contabilização do RADIUS com base de dados auxiliar.

conceitos

Accounting, mensagens de accounting e o encaminhamento destas através de um servidor proxy.

Introdução 11 Padrão RADIUS original era apenas AA (Autenticação e Autorização).

q

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 autenticação. 11 Finalidade do accounting: 22 F ornecer informações sobre a autenticação de um usuário. 22 Facilitar a contabilidade de utilização de usuários (originalmente em PPP, telnet e rlogin). 11 Possibilidade de: 22 Monitoramento e coleta de estatísticas. 22 Cobrança por utilização. Introduzido em 1997, o RADIUS Accounting surgiu para complementar o padrão RADIUS. Até então o padrão RADIUS provia apenas as funcionalidades de autenticação e autorização. Com essa extensão, foi possível prover o “triplo A” (Autenticação, Autorização e Accounting – AAA). Por padrão, utiliza-se a porta UDP 1813 para envio das mensagens, ou seja, uma porta diferente da usada para autenticação. A RFC original, RFC 2059, foi atualizada pelas RFCs 2139 e 2866, esta última de junho de 2000.

Capítulo 8 - RADIUS Accounting: conceitos e finalidade

objetivos

RADIUS Accounting: conceitos e finalidade

129

Esse padrão surgiu com a finalidade de fornecer informações sobre os eventos de autenticação de usuários, consequentemente facilitando o acompanhamento com relação aos pedidos gerados por um cliente. Como exemplo dessa funcionalidade, é possível extrair informações como o status da autenticação, se essa foi realizada com sucesso ou não e em qual autenticador (Ponto de Acesso em nosso contexto) o usuário está se associando. Além de levantar estatísticas sobre os eventos de autenticação de usuários, através do RADIUS accounting também é possível determinar o tempo de conexão de um usuário e registrar dados como quantidade de pacotes e bytes consumidos.

RADIUS Accounting 11 Segue o mesmo padrão cliente-servidor do RADIUS.

q

11 Autenticador (cliente RADIUS) é responsável por solicitar o registro e também por encaminhar as informações de accounting ao servidor RADIUS. 11 Servidor RADIUS accounting deve apenas responder ao autenticador com mensagem indicando sucesso ou não no atendimento da requisição. 11 A segurança é provida pela mesma senha compartilhada pelo método de autenticação (shared secret). O RADIUS accounting é um complemento ao padrão já existente até então e, portanto, segue o modelo cliente-servidor já utilizado pelo RADIUS. O autenticador deve solicitar ao servidor RADIUS que inicie o registro de certa métrica. O autenticador também é responsável por enviar posteriormente os dados a serem armazenados, como veremos em um exemplo adiante. O servidor de autenticação deve sempre sinalizar se as requisições foram ou não atendidas, através de mensagens de sucesso ou falha. A segurança, por padrão, é fornecida pelo mesmo método utilizado na comunicação 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 configurada manualmente pelo administrador em ambos os equipamentos). Também é possível Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

utilizar o RadSec como suporte a esse envio das mensagens de contabilidade. Sendo assim,

130

a segurança a ser fornecida fica apoiada no TLS, como veremos mais detalhadamente a seguir.

Accounting e RadSec 11 No RadSec, todas as operações são realizadas na mesma porta TCP (2083).

q

11 Não existem portas distintas para autenticação/autorização e contabilização. 11 Se o servidor RadSec não estiver configurado para accounting, ele deve sinalizar tal fato ao requisitante. Quando o RadSec é usado, não haverá uma porta separada para o RADIUS accounting. Essa funcionalidade é implementada na mesma porta TCP usada pelo RadSec para as funções de autenticação e autorização (porta 2083). Se o servidor RadSec em questão não estiver configurado para realizar contabilização, 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: extensão não suportada).

Mensagens de accounting 0

7 Code

15 Identifier

31 Length

Authenticator

Figura 8.1 Formato da mensagem de accounting do RADIUS .

Attribute O RADIUS Accounting utiliza dois tipos de mensagem. A mensagem de solicitação de contabilização, Accounting-Request (tipo 4) e a mensagem de resposta a essa solicitação, Accounting-response (tipo 5). Essas mensagens seguem o mesmo formato das mensagens do RADIUS (exemplo: Access-Request). 11 Accounting-Request é a mensagem de solicitação ao servidor no início, na finalização e na atualização de “status” intermediariamente à contabilização. 11 Accounting-Response é a mensagem responsável 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 informações particulares, assim como identificadores de início e fim da gravação de uma sessão. Serão 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 início, o fim e se a sessão se encontra ativa. 11 Acct-Delay-Time: é o atributo responsável por indicar quanto tempo o autenticador tem para enviar uma mensagem de “status” ao servidor. Caso não seja recebida uma mensagem nesse tempo determinado, uma requisição (Accounting-Request) pode ser utilizada para solicitar tal informação ao autenticador. 11 Acct-Session-Id: é o atributo que identifica uma sessão. A partir desse atributo a administração de um registro de início e fim de uma sessão se torna mais simples, uma vez 11 Acct-Session-Time: indica o tempo em que o usuário esteve associado. Responsável pela contabilização do tempo total de uso, esse atributo estará presente somente quando a sessão for finalizada. 11 Acct-Input-Packets: carrega a informação de quantos pacotes foram recebidos através da porta associada ao usuário no autenticador. Esse atributo também serve para contabilização do uso dos recursos da rede e é enviado somente ao final da sessão pelo autenticador ao servidor. 11 Acct-Output-Packets: carrega a informação de quantos pacotes foram transmitidos para a porta associada ao usuário no autenticador. Assim como Acct-Input-Packets, esse atributo também serve para contabilização do uso dos recursos da rede e é enviado somente ao final da sessão pelo autenticador ao servidor

Capítulo 8 - RADIUS Accounting: conceitos e finalidade

que ambos possuem o mesmo valor.

131

1

7 Tipo

15 Tamanho

31 Valor

Valor (cont)

Os atributos podem depender do fabricante. Alguns produtos podem fornecer informações de forma diferente de outros.

Atributos Acct-Status-Type Responsável por informar o status da sessão (início, fim ou ativa):

Type

40 for Acct-Status-Type. Length 6 Value (8 octetos) 1 Start 2 Stop 3 Interim-update ...

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

O atributo Acct-Status-Type é o mais importante atributo para a funcionalidade de accounting.

132

Ele tem a finalidade de informar ao servidor RADIUS Accounting o início, o fim de uma sessão 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 criação, manutenção e finalização de sessão.

Figura 8.2 Formato da mensagem de atributos do accounting.

Troca de mensagens Servidor RADIUS

Autenticador RADIUS: Accounting-Request (4) [acct_status_type=start]

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, contém a identificação do usuário, o endereço de rede, a identificação do NAS e um identificador único de sessão. A fim de informar ao servidor RADIUS accounting que a conexão 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 sessão do cliente e a data. Quando o acesso é finalizado, o autenticador envia um sinal do tipo “stop” (uma mensagem do tipo Accounting-Request com atributo Acct-Status-Type = stop). Onde, além da informação de finalização do registro de contabilização, geralmente carrega informações Accounting-Request deve ser respondida por uma mensagem Accounting-Response, enviada pelo servidor RADIUS. Essa mensagem funciona como uma confirmação de recebimento (um ACK).

Accounting e roaming O encaminhamento das mensagens de accounting via proxy é realizado da mesma forma como é feito o encaminhamento das mensagens de autenticação. 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 contabilização por ele repassados. Nesse caso, se considerarmos o serviço eduroam, os dados poderão ser registrados tanto pela instituição de origem como pela instituição visitada.

Capítulo 8 - RADIUS Accounting: conceitos e finalidade

do tempo, dados transferidos e motivo da desconexão. Como dissemos, cada mensagem

133

Atividade Prática 7 e Configuração do accounting e banco de dados PostgreSQL Resumo dos dados utilizados nesta atividade prática Usuário administrador da base de dados.

RADIUS

Senha do usuário administrador da base de dados.

RADIUS

Senha compartilhada entre o servidor RADIUS da instituição (aluno) e o RADIUS da federação (professor).

Usualmente: eduroam123

Arquivos editados Liberação para acesso à base de dados.

/etc/postgresql/8.4/main/pg_hba.conf

Arquivo SQL com a estrutura de tabelas para o RADIUS.

/etc/freeradius/sql/postgresql/schema.sql

Arquivo de comunicação entre o FreeRADIUS e o PostgreSQL.

/etc/freeradius/sql.conf

Arquivo de habilitação do módulo de Accounting no FreeRADIUS.

/etc/freeradius/sites-enable/inner-tunnel (padrão) Ou se você seguiu o tutorial e criou um arquivo novo, chamado “eduroam” /etc/freeradius/sites-enable/eduroam

Liberação do carregamento do módulo SQL.

/etc/freeradius/radiusd.conf

Arquivo com a query responsável pelo armazenamento das respostas e requisições.

/etc/freeradius/sql/postgresql/diaulup.conf /etc/phppgadmin/apache.conf

Configuração do acesso à interface do phppgadmin.

Ou /etc/apache2/conf.d/phppgadmin

T Ra CP/ dS TL ec S -

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

134

Servidor RADIUS Federação

Ponto de Acesso

Usuário

STL P/ c TC dSe Ra

Relatórios

Servidor RADIUS Instituição 2 Servidor RADIUS Instituição 1

Servidor RADIUS Instituição 2

Servidor LDAP Instituição 1

A sétima e última prática tem como objetivo configurar a funcionalidade de accounting (contabilização) dos pedidos de autenticação no RADIUS através do uso de uma base de dados relacional utilizando o PostgreSQL, possibilitando maior controle sobre o uso do serviço eduroam em uma instituição de ensino e pesquisa.

Instalação e configuração do suporte ao accounting O accounting fornece informações muito importantes para o controle de acesso e posterior análise dos usuários. Somente com o accounting será possível o administrador descobrir

Figura 8.4 Indicação da prática, configuração da geração de relatórios no servidor RADIUS da instituição.

a qual usuário um certo IP estava associado em um dado momento. É relevante também 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 disponíveis.

Instalação do PostgreSQL A instalação do banco de dados PostgreSQL é simples e necessita de pouca configuração para que esteja em funcionamento. Sendo assim, é necessário 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 administração remota da base de dados, verifique o arquivo contido em /etc/postgresql/8.4/main/pg_hba.conf. Recomendamos adicionar também o conteúdo indicado a seguir, que representa a liberação do usuário “radius” localmente à base denominada “radius” (que futuramente será criada).

local

radius

radius md5

Após a instalação do banco de dados, passamos à etapa de criação 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 distribuição com base em pacotes (exemplo: Ubuntu ou Debian), é necessário apenas instalar o pacote com as informações e módulos necessários ao acesso SQL.

# apt-get install freeradius-postgresql O próximo passo, depois de instalado o suporte ao banco de dados, é criar o usuário “radius”, que administrará a base de dados chamada “radius”. A base de dados “radius” vai conter todas as tabelas necessárias para que o sistema de accounting funcione.

# 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, serão 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 usuário.

Capítulo 8 - RADIUS Accounting: conceitos e finalidade

# su - postgres

11 -W para pedir a senha do usuário. 135

11 -d o nome da base de dados. 11 -h o endereço do host postgres. 11 -f o arquivo de importação. Neste momento, já temos tanto a base de dados como o usuário que a administrará criados e configurados. Então, devem-se configurar os arquivos referentes ao FreeRADIUS para habilitar a gravação no banco de dados. Os arquivos do FreeRADIUS que deverão ser alterados são: 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 usuário “radius” e o endereço 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”

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

... } É necessário habilitar o accounting nos arquivos de configuração do FreeRADIUS, que já estão configurados em sua instalação. Esses arquivos são apresentados a seguir. Configuração 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 ... } ... Configuração do arquivo /etc/freeradius/radiusd.conf.

... modules { $INCLUDE ${confdir}/modules/ $INCLUDE eap.conf $INCLUDE sql.conf } ... Para que sejam armazenadas as requisições e respostas de forma simultânea para solicitações de autenticação dos usuários, é necessário realizar a configuração do arquivo

... 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 visualização dos dados de accounting, pode-se utilizar o phppgadmin. Para

Capítulo 8 - RADIUS Accounting: conceitos e finalidade

/etc/freeradius/sql/postgresql/dialup.conf, conforme indicado a seguir.

isso, é necessário 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 padrão, o phppgadmin aceitará somente conexões vindas da máquina 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. Porém, caso exista apenas o arquivo /etc/phppgadmin/apache.conf, copie-o para /etc/apache2/conf.d/phppgadmin.

Alias /phppgadmin /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 php_flag magic_quotes_gpc Off

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

php_flag track_vars On

138

php_value include_path .

# cp /etc/phppgadmin/apache.conf /etc/apache2/conf.d/phppgadmin É necessário reiniciar o servidor web Apache para que as configurações tenham efeito.

# /etc/init.d/apache2 restart Para acessar a interface web do phppgadmin, utilize o navegador da máquina 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 usuário RADIUS, que criamos durante a ativação do accounting.

Figura 8.5 Tela de acesso do phppgadmin.

Uma vez autenticado no sistema, deverá ser selecionada a base de dados que desejamos

Figura 8.6 Seleção do banco de dados ‘radius’.

Os dados armazenados na tabela radpostauth equivalem à resposta da solicitação de autenticação do cliente, e pode ser visualizada pela Figura 8.7. A partir desse relatório, é simples encontrar se um acesso foi negado ou aceito a um usuário em especial, e em qual momento isso ocorreu.

Capítulo 8 - RADIUS Accounting: conceitos e finalidade

administrar, no caso, a base chamada RADIUS. Como pode ser visto na Figura 8.6.

139

Diversos dados podem ser habilitados para a coleta pelo accounting e armazenados no banco de dados, aumentando assim as possibilidades de controle e avaliação do ambiente RADIUS administrado.

Outras ferramentas de visualização

Figura 8.7 Relatório de requisição de autenticação dos usuários.

11 freeradius-dialupadmin: também chamado de dial-up admin, é baseado em PHP, gratuito e suporta consultas às bases de dados MySQL e PostgreSQL, ou ainda consulta direta à

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

base LDAP.

140

Figura 8.8 Tela inicial do freeradiusdialupadmin.

11 Raptor: é uma ferramenta baseada em software livre e de distribuição gratuita. É um software voltado para visualização de informação de accounting e autenticação, e muito utilizado para ambiente de provedor de identidade e de serviços com uso do Shibboleth.

Figura 8.9 Tela capturada de visualização de estatísticas para o Raptor.

Há também a possibilidade de desenvolvimento de ferramentas específicas pelas instituições que fornecem o serviço eduroam, fazendo consultas ao banco de dados utilizado para o armazenamento das informações de accounting. Um exemplo é a ferramenta desenvolvida pela equipe da Unicamp, instituição participante do piloto eduroam no Brasil.

Considerações finais Neste livro, apresentamos o serviço eduroam, um serviço de acesso sem fio seguro, baseado no conceito de federação e oferecido para a comunidade internacional de edufuncionários das instituições acadêmicas participantes da federação, pois permite a autenticação segura, o transporte seguro de dados em redes sem fio e a mobilidade de usuários entre instituições. Como vimos, seu funcionamento é apoiado por uma série de padrões 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 contribuído para a sua adoção rápida e fácil em instituições de ensino e pesquisa no Brasil.

Capítulo 8 - RADIUS Accounting: conceitos e finalidade

v

Assista ao vídeo demonstrativo “Sistema para visualização das informações de accounting” em: http:// www.youtube.com/ watch?v=ZQQSlEpE_qg.

cação e pesquisa. O eduroam é um facilitador da colaboração entre alunos, professores e

141

142

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

Bibliografia 11 GAST, M. 802.11: Wireless Networks: The Definitive Guide. 2nd Edition. Editora O’Reilly, 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).

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

11 [RFC 5216] The EAP-TLS Authentication Protocol D. Simon, B. Aboba, R.

143

Padrões 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 -

Eduroam: acesso sem fio seguro para Comunidade Acadêmica Federada

Port-Based Network Access Control (2010 revision).

144

Débora Christina Muchaluat Saade é professora associada do Departamento de Ciência da Computação da Universidade Federal Fluminense (UFF). É engenheira de computação formada pela PUC-Rio e possui mestrado e doutorado em informática pela mesma universidade. É bolsista de produtividade em Desenvolvimento Tecnológico e Extensão Inovadora pelo CNPq e foi Jovem Cientista do Estado do Rio de Janeiro pela Faperj. Suas áreas de pesquisa são redes de computadores, redes sem fio, sistemas multimídia e hipermídia, 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 instituições, implantando o serviço piloto eduroam no Brasil.

Ricardo Campanha Carrano é engenheiro de telecomunicações formado em 1995 pela Universidade Federal Fluminense. Em 2008, obteve o título de Mestre em Engenharia de Telecomunicações pela mesma instituição e atualmente cursa o doutorado em Computação, também na UFF, onde atua como Professor do Departamento de Engenharia de Telecomunicações. Foi empresário e participou da implantação de provedores de acesso no início 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 Informação pela Faculdade Metodista Granbery em 2006, e obteve o título de Mestre em Computação pela Universidade Federal Fluminense em 2011. Atualmente é Doutorando em Computação pela Universidade Federal Fluminense. Participou de diversos projetos de pesquisa, possuindo experiência na área de Ciência da Computação, com ênfase em redes, atuando principalmente nos temas relacionados a redes sem fio, Internet do Futuro e segurança.

LIVRO DE APOIO AO CURSO

O curso aborda os conhecimentos necessários para a construção do ambiente de autenticação seguro e distriserá capaz de integrar a sua instituição ao serviço de acescação e pesquisa, permitindo que estudantes, pesquisadores e equipe de TI de instituições participantes acessem quando visitam outras instituições integradas ao serviço. Este livro inclui os roteiros das atividades práticas e o conteúdo dos slides apresentados em sala de aula, apoiando suas organizações ou localidades de origem.

ISBN 978-85-63630-25-4

9 788563 630254