Implementação de um Modelo de Segurança para Rede Sem Fio WPA2-EAP

(1)

UNIVERSIDADE REGIONAL DO NOROESTE DO ESTADO

DO RIO GRANDE DO SUL

DCEENG – DEPARTAMENTO DE CIÊNCIAS EXATAS E

ENGENHARIAS

CURSO DE GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO

ROGER CASAGRANDE DE MEDEIROS

Implementação de um Modelo de Segurança

para Rede Sem Fio WPA2-EAP

Santa Rosa (RS)

2017

(2)

ROGER CASAGRANDE DE MEDEIROS

Implementação de um Modelo de Segurança para

Rede Sem Fio WPA2-EAP

Trabalho de Conclusão de Curso apresentado ao Colegiado de Coordenação do Curso de Ciência da Computação da Universidade Re-gional do Noroeste do Estado do Rio Grande do Sul (UNIJUÍ), apresentado como requisito parcial para obtenção do Título de Bacharel em Ciência da Computação.

Orientador: Professor Dr. Gerson Battisti

Santa Rosa (RS)

2017

(3)

ROGER CASAGRANDE DE MEDEIROS

Implementação de um Modelo de Segurança para

Rede Sem Fio WPA2-EAP

Trabalho de Conclusão de Curso apresentado ao Colegiado de Coordenação do Curso de Ciência da Computação da Universidade Re-gional do Noroeste do Estado do Rio Grande do Sul (UNIJUÍ), apresentado como requisito parcial para obtenção do Título de Bacharel em Ciência da Computação.

Trabalho __provado. Santa Rosa (RS), __ de julho de 2017:

Professor Dr. Gerson Battisti

Orientador

Professor Dr. Sandro Sawicki

Banca

Santa Rosa (RS)

2017

(4)

Dedico este trabalho à minha amada família, com gratidão pelo carinho, compreensão

(5)

AGRADECIMENTOS

Agradeço a minha família, minha Mãe Tânia, meu Pai José Vilson, por sempre acreditarem em mim e por todo amor depositado.

A minha Avó Teresinha, por sempre se fazer presente e preparar doces deliciosos. Aos amigos Marcos Sulzbach Morgenstern, Lori Ronaldo Flores Machado Filho, Amanda Preissler, Bruno Rodrigues Campos, DCAST e jomp16, que estiveram presentes no período acadêmico de diversas formas, e que ainda estarão presentes.

Ao meu orientador, professor Gerson Battisti, pela atenção dada ao trabalho durante o desenvolvimento, dicas e sugestões de forma profissional que me instigou a procura de conhecimentos na área de Redes de Computadores no decorrer da graduação. Aos professores que se fizeram presentes no período acadêmico, de forma profissio-nal em suas formas de ministrar as disciplinas como nos momentos de descontração.

(6)

“O vencedor não será perguntado se ele falou a verdade” - Adolf Hitler

(7)

RESUMO

Atualmente as redes sem fio que possuem autenticação por WPA2-EAP, estão majoritaria-mente presentes em ambientes corporativos, e requerem servidor de RADIUS, porém há poucos métodos que permitam aplicar politicas que restringem de onde um cliente sem fio pode autenticar, ou seja, a partir de quais pontos de acesso ele pode aceder. Tem-se em vista, implementar um modelo de segurança que permita verificar se o ponto de acesso origem pode ser acessado por um cliente que pertence a um determinado grupo, constando no grupo, seus membros e os endereços IPs dos pontos de acesso que estão autorizados aceder a rede sem fio, e permitir que seja acessado outras bases de dados. A fim de cumprir os objetivos, será configurado a verificação de elegibilidade de grupo sobre o software FreeRADIUS, sendo atendido também o acesso para múltiplas bases de dados, e por fim testar as configurações implementadas. Obteve-se resultados positivos da implementação através dos testes realizados, que viabilizou a restrição de onde um usuário pode aceder a rede sem fio, como também acessar três diferentes bases de dados em locais distintos, e essas sendo elas MariaDB, OpenLDAP e Active Directory.

Palavras-chave: Rede Sem Fio, Protocolo 802.1X, RADIUS, Banco de Dados, SQL,

(8)

ABSTRACT

Currently wireless networks with WPA2-EAP authentication are majorly present in corporate environments, and require a RADIUS server, but there are few methods to enforce policies that restrict where can a wireless client authenticate, that is, from which access points he can access. It’s our intention implementing a security model that allows verifying if the source access point can be accessed by a client belonging to a particular group, including the group, its members and the IP addresses of the access points which are authorized to access the wireless network, and allow other databases to be accessed. In order to fulfill the objectives, the group eligibility verification on the FreeRADIUS software will be set up - access to multiple databases will also be attended - and finally, the implemented configurations will be tested. Positive results were achieved through the tests performed, which enabled the restriction of where a user could access the wireless network, as well as access to three different databases in different locations, such as MariaDB, OpenLDAP and Active Directory.

Keywords: Wireless Network, 802.1X Protocol, RADIUS, Database, SQL, LDAP, WPA2,

(9)

LISTA DE ILUSTRAÇÕES

Figura 1 – Exemplo de uma rede WLAN . . . 17

Figura 2 – Estrutura de uma Extended Service Set (ESS) . . . 19

Figura 3 – Esquema do protocolo de segurança WEP . . . 21

Figura 4 – Esquema de autenticação do protocolo WPA-PSK . . . 22

Figura 5 – Esquema do protocolo de criptografia WPA2-PSK AES-CCMP . . . . 23

Figura 6 – Autenticação 802.1X . . . 25

Figura 7 – Conceito base do FreeRADIUS . . . 28

Figura 8 – Esquema exemplo de LDAP . . . 30

Figura 9 – Cenário de Implementação . . . 33

Figura 10 – Configuração de acesso ao Banco de Dados . . . 35

Figura 11 – Usuários adicionados à tabela radcheck . . . 35

Figura 12 – Grupos e Usuários adicionados à tabela radusergroup . . . 36

Figura 13 – Condicionais configurados na tabela radgroupcheck . . . 36

Figura 14 – Configuração de acesso ao OpenLDAP no arquivo ldap . . . 37

Figura 15 – Usuário e Grupo cadastrado no OpenLDAP . . . 38

Figura 16 – Configuração de acesso ao Active Directory no arquivo ldap . . . 39

Figura 17 – Atributo allowedIP com dois IPs . . . 40

Figura 18 – Senha no formato de texto e hexadecimal do User2 . . . 40

Figura 19 – Arquivo Default com as condicionais de acesso aos BD . . . 42

Figura 20 – Arquivo inner-tunnel . . . 43

Figura 21 – Log do FreeRADIUS referente a autenticação do User5 . . . 45

(10)

LISTA DE TABELAS

Tabela 1 – Protocolos de segurança em Redes Sem Fio . . . 23 Tabela 2 – Grupos que os usuários pertencem . . . 44

(11)

LISTA DE ABREVIATURAS E SIGLAS

802.1X Port Based Network Access Control

AAA Authentication, Authorization and Accounting AD Active Directory

ADSL Asymmetric Digital Subscriber Line AES Advanced Encryption Algorithm AP Access Point

BD Banco de Dados BSS Basic Service Set

CCMP Counter-Mode/Cipher Block Chain Message Authentication Code Pro-tocol

CN Common Name DC Domain Controller

DFS Dynamic Frequency Selection DN Distinguished Name

EAP Extensible Authentication Protocol ESS Extended Service Set

FR FreeRADIUS

IEEE Institute of Electrical and Electronics Engineers IP Internet Protocol

IPsec Internet Protocol Security L2TP Layer 2 Tunneling Protocol LAN Local Area Network

LDAP Lightweight Directory Access Protocol MAC Media Access Control

(12)

MS-CHAP Microsoft Challenge-Handshake Authentication Protocol MT MikroTik

MV Máquina Virtual NAS Network Access Server OU Organizational Unit

PEAP Protected Extensible Authentication Protocol PPPoE Point-to-Point Protocol over Ethernet

PSK Pre-Shared Key

RADIUS Remote Authentication Dial-In User Service RAM Random Access Memory

RC4 Rivest Cipher 4 SO Sistema Operacional

SQL Structured Query Language TCP Transmission Control Protocol TKIP Temporal Key Integrity Protocol TLS Transport Layer Security

UDP User Datagram Protocol VLAN Virtual Local Area Network VPN Virtual Private Network WAN Wide Area Network

WDS Wireless Distribution System WEP Wired Equivalent Privacy WLAN Wireless Local Area Network WPA Wi-Fi Protected Access

(13)

SUMÁRIO

1 Introdução . . . . 14 2 Rede Wireless . . . . 17 2.1 Arquitetura . . . 18 2.1.1 BSS . . . 18 2.1.2 ESS . . . 18 2.2 Segurança . . . 19

2.3 Protocolos de Segurança em WLANs . . . 20

2.3.1 Protocolo WEP . . . 20

2.3.2 Protocolo WPA . . . 21

2.3.3 Protocolo WPA2 . . . 22

2.3.4 Modo PSK . . . 23

2.3.5 Modo EAP . . . 24

3 Segurança Modo EAP . . . . 25

3.1 802.1X . . . 25 3.2 RADIUS . . . 26 3.2.1 FreeRADIUS . . . 27 3.3 MariaDB . . . 28 3.4 LDAP . . . 29 3.4.1 OpenLDAP . . . 29 3.4.2 Active Directory . . . 30

4 Proposta de Modelo de Segurança . . . . 32

4.1 Cenário de Implementação . . . 32

4.2 Implementação . . . 34

4.2.1 Implementação com Banco de Dados MariaDB . . . 34

4.2.2 Implementação com o OpenLDAP . . . 36

4.2.3 Implementação com Active Directory . . . 38

4.2.4 Implementação com o FreeRADIUS . . . 41

5 Avaliação do Modelo Proposto . . . . 44

5.1 Teste 1: Usuário cadastrado em um único local . . . 45

5.2 Teste 2: Usuário cadastrado em dois BD . . . 45

5.3 Teste 3: AP não autorizado para o GrupoC . . . 46

5.4 Teste 4: Usuário não encontrado . . . 47

(14)

6 Conclusão . . . . 50

(15)

14

1 INTRODUÇÃO

A segurança de uma rede de computadores privada por meio de acesso sem fio é facilmente comprometida devido aos meios de autenticação, que são por senha pré-compartilhada e autenticação via RADIUS (Remote Authentication Dial-In User Service). Os dados utilizados para a autenticação podem ser obtidos através de softwares maliciosos que executam sobre o dispositivo, por meio de acesso físico ao mesmo e também através da engenharia social. Por consequência de tais fatos, consegue-se acesso a dados restritos que necessitam de privilégios ou utilização de recursos de rede que estão à disposição dos usuários autênticos, podendo também usufruir dessa rede para atividades criminosas no âmbito de obter anonimato sobre a autoria do crime que ocorreu.

As vulnerabilidades em uma rede local podem permitir intrusões indesejadas onde os objetivos do intruso podem ser desde uma pequena sabotagem a ataques para uma determinada rede de uma empresa na tentativa de incriminar a rede origem, resultando em investigações criminais. Para mitigar vulnerabilidades, são buscadas soluções que aumentam a segurança das redes locais visando autenticação dos dispositivos que conectam-se as redes, para que posteriormente seja identificado qual dispositivo causou distúrbios à rede em que está conectado.

A falta de autenticação, ou seja, não dizer quem está se conectando a rede, facilita a ocorrência de problemas relacionados a sequestro de dados, alteração de configurações em equipamentos de rede permitindo obter alguma espécie de vantagem ou violar determinadas regras de conduta, como acessar e distribuir conteúdo ilícito. A consequência dessa não autenticação é que não consegue-se identificar o real autor daquelas ações, mesmo que tenha em mãos um endereço IP (Internet Protocol) e um Mac Address.

É necessário que cada usuário tentando-se autenticar, mostre seu documento de identificação para a rede, permitindo que seja atrelado ao seu nome de usuário, um endereço IP que será usado e o Mac Address da placa de rede do equipamento em uso para acessar a rede. Quando ocorrer qualquer problema onde tenha-se o endereço IP ou Mac Address em mãos, identifica-se rapidamente qual usuário foi o autor das atividades ilícitas ou que violou alguma regra de conduta de uso da rede estipulado pela organização administradora dessa rede computacional. Caso seja um crime contra outra organização, tentativa de interromper os recursos de rede ou até quando há processo judicial sobre o administrador, com a identificação desse usuário autenticado, torna-se possível mover o processo para o usuário como também proporcionar demissão por justa causa, assim eliminando ou diminuindo prejuízos a organização administradora da rede.

(16)

15

como o nome de usuário e senha que permita que o processo seja realizado. A configuração da rede sem fio tipicamente encontrada, é uma rede que não requer autenticação no inicio desta conexão e requisita o login através de um portal captivo quando é feito uma tentativa de acesso à Internet. A consequência deste tipo de autenticação permite que um usuário mal intencionado possa explorar a estrutura da rede local com intenção de procurar informações para afetar o desempenho dessa infraestrutura como também deixar inacessível serviços de rede para usuários legítimos.

O controle de autenticação baseado em localização do ponto de acesso é uma aplicação atípica em ambientes empresariais. A finalidade de controlar esse acesso via localização, busca restringir os locais que um usuário pode usufruir da rede, como por exemplo: acessar a partir e somente no departamento que está alocado e sendo negado sua autenticação nos demais pontos de acesso sem fio. Isso auxilia no incremento da camada de segurança da rede, sendo que possa ocorrer eventualmente que esse usuário venda seus dados de login para pessoas de má fé, mas por exigir que haja a autenticação em determinados pontos de acesso, minimiza a chance de sucesso do invasor conseguir entrar na rede não estando fisicamente no departamento que o usuário está alocado.

Justifica-se a necessidade de implementar uma configuração que permite aceder diferentes bases de dados, não sendo necessariamente de mesmo tipo. Isso torna possível ter base de dados específica para visitantes, usuários temporários e remotos, onde ocorrem com maior frequência alterações desses dados. Cria-se possibilidade dos colaboradores do setor de Tecnologia da Informação terem permissão de acordo com seu cargo para editarem os dados dessa base secundária, não deixando que tais colaboradores tenham permissões desnecessárias que possam ocasionar problemas criminais relacionado a base de dados principal, além que permitiria utilizar outras plataformas para armazenamento de bases de dados alternativas.

Para ter maior controle sobre de onde o usuário deve autenticar-se, necessita implementar grupos de acesso, os quais armazenarão os pontos de acesso liberados para autenticação e quais usuários fazem parte desse grupo. Essa política permite que a autenticação seja aceita quando o ponto de acesso fonte está presente no grupo do usuário informado para aceder a rede. Se este ponto de acesso não está presente no grupo, a autenticação será recusada mesmo que as credenciais informadas estejam corretas.

Os argumentos sobre segurança que foram mencionados nos parágrafos acima, relatam o porque de implementar acesso a mais de um tipo de base de dados, permitir que grupos de usuários possam logar em determinados pontos de acesso e recusar nos demais, utilizar a criptografia WPA2-EAP para dificultar obtenção de informações sigilosas e por fim receber concessão de IP somente após autorizado o login na rede sem fio.

(17)

16

a confiabilidade e identificação dos usuários no momento que acessarem uma rede sem fio. Utilizaremos os softwares FreeRADIUS, MariaDB e OpenLDAP, que são gratuitos e possuem o código fonte aberto, transformando-se uma alternativa de baixo custo de implementação. Também se utilizará o Active Directory, a fim de demonstrar que a solução gratuita possui suporte para o banco de dados presente em um Sistema Operacional proprietário. Essa implementação permitirá que os dados possam estar distribuídos e disponíveis em mais de um banco de dados.

Portanto esta pesquisa será dividida da seguinte forma: o Capítulo 1 introduzirá este trabalho e mencionará o porque e os objetivos. O Capítulo 2 tratará sobre o emba-samento teórico em redes sem fio. O Capítulo 3 tratará sobre dois protocolos e bancos de dados. O Capítulo 4 demonstrará o cenário a ser utilizado e as implementações que este trabalho realizará. O Capítulo 5 tratará sobre a avaliação da implementação e os testes que serão realizados. E por fim, o Capítulo 6 falará sobre a conclusão e trabalhos futuros que possam agregar novas funcionalidades baseadas na presente implementação deste trabalho.

(18)

17

2 REDE WIRELESS

Barbosa (2013, p.9) afirma que uma WLAN (Wireless Local Area Network):

[...] é uma rede local sem fios que usa ondas de rádio ou infravermelhos, para estabelecer ligação entre dispositivos de rede. Esta tecnologia utiliza espalhamento espectral (utilizado sempre com modulação) ou apenas modulação (sem espalhamento espectral), permitindo assim a comunica-ção entre dispositivos numa área limitada. O Institute of Electrical and Electronics Engineers (IEEE) contém um grupo chamado de Wireless Local Area Networks Standard Working Group que visa criar modelos para redes sem fio, que define o nível físico para rede e o protocolo de controlo de acesso ao meio (Distributed Foundation Wireless MAC). [...]

Segundo Forouzan (2008), a comunicação pelo meio sem fio está a cada dia aumentando devido a demanda dos dispositivos que permitem conectar-se a redes locais sem fio. As WLANs são tipicamente encontradas em campi universitários, órgãos públicos, empresas do setor comercial e até em áreas abertas de uso público como praças, eventos locais, shoppings e aeroportos. A Figura 1 é um exemplo de rede WLAN.

Figura 1: Exemplo de uma rede WLAN

Fonte: Maia (2003, p.1) Segundo Tanenbaum (2003, p.231):

(19)

18

Embora a Ethernet seja amplamente utilizada, ela está prestes a enfrentar alguma concorrência. As LANs sem fios estão cada vez mais populares e um número crescente de edifícios de escritórios, aeroportos e outros lugares públicos estão sendo equipados com elas. As LANs sem fios podem operar em duas configurações, como vimos na Figura 1.35: com e sem uma estação base. Conseqüentemente, o padrão de LAN 802.11 leva em conta esse fato e prevê ambas as organizações [...]

2.1 Arquitetura

A definição da arquitetura do IEEE 802.11 é composta por dois tipos de serviços básicos, sendo estes o BSS (Basic Service Set) e o ESS (Extended Service Set), poderíamos chama-lo também de tipos de topologia de rede sem fio.

2.1.1 BSS

Kurose e Ross (2010, p.387) afirmam que um BSS é:

[...] O bloco construtivo fundamental da arquitetura 802.11 é o conjunto básico de serviço (basic service set – BSS). Um BSS contém uma ou mais estações sem fio e uma estação-base central, conhecida como um ponto de acesso (access point – AP) na terminologia da 802.11.

Segundo Forouzan (2008, p.421) sobre BSS:

O IEEE 802.11 define o BSS (Basic Service Set) como a base de uma rede LAN sem fio (WLAN). Uma BSS é formada por estações wireless fixas ou móveis e, opcionalmente, por uma estação-base central conhecida como AP (Access Point). [...] Uma BSS sem um AP é uma rede isolada e independente que não pode transmitir dados para outras BSSs. Essa arquitetura é denominada arquitetura ad-hoc. Nessa arquitetura, as estações podem formar uma rede sem a necessidade de um AP; são capazes de se localizar e concordar entre si em fazer parte de uma BSS. Uma BSS com um AP é chamada rede de infra-estrutura.

2.1.2 ESS

Forouzan (2008, p.422) afirmam que uma ESS é:

[...] formada por duas ou mais BSSs com APs. Nesse caso, as BSSs são conectadas por meio de um sistema de distribuição que normalmente é uma LAN com fio. O sistema de distribuição interliga as BSSs via APs. O IEEE 802.11 não restringe o sistema de distribuição; ele pode ser qualquer tipo de rede LAN padrão IEEE, por exemplo, uma Ethernet. Note que uma ESS é composta por dois tipos de estação: móveis e fixas. As estações móveis são as comuns de uma BSS. As estações fixas são aquelas especiais, do tipo AP, que são interconectadas por uma LAN com fio. [...]

(20)

19

Segundo Huotari (2015, p.1), ainda consiste uma ESS quando uma estação móvel se desloca de uma BSS para a outra que esteja próxima e sendo que haverá uma nova associação à este outro BSS.

Na Figura 2 é apresentado a topologia de uma estrutura ESS. Figura 2: Estrutura de uma Extended Service Set (ESS)

Fonte: Sobral (2013, p.1)

2.2 Segurança

Sobre segurança o Tseng (2005, p.1) diz que:

Devido ao rápido crescimento em popularidade da Rede Local Sem Fio (WLAN), a segurança de rede sem fio tornou-se uma das muitas questões importantes de pesquisa. Em uma rede WLAN, os dispositivos usam um meio sem fio (ou seja, ondas de rádio) para comunicar-se com cada outro dispositivo. É fácil para invasores interceptarem comunicações ou acesso para WLANs, tanto que há mais ameaças à segurança do que as redes com fio. [...]

E Fan, Lin e Hsu (2013, p.1) dizem o porquê é necessário ter autenticação:

[...] é o processo de verificação das identidades dos usuários quando eles querem acessar recursos disponíveis na rede. Tipicamente, um usuário provê seus fatores de autenticação para um servidor, e então o servidor verifica-os. Se os fatores estão corretos, o usuário é autorizado e ganha acesso para os recursos providos pelo servidor, e também o servidor gera um material chamado de chave de sessão o qual é compartilhado com o usuário. Semelhantemente, é também crucial para as Redes Locais Sem Fio, pois necessita autenticar usuários e construir com eles canais seguros de comunicação. [...]

(21)

20

2.3 Protocolos de Segurança em WLANs

Sobre os protocolos de segurança, Keeratiwintakorn e Krishnamurthy (2005, p.4) dizem que:

O protocolo de segurança em nível de pacote é usado para prover serviços de segurança tal como criptografia de mensagens e autenticação para cada pacote no nível de pacote ou frame. Cada frame IEEE 802.11 é criptografado usando uma chave criptográfica e autenticado via uma mensagem de código de autenticação (MAC) com uma chave de auten-ticação. Isto previne usuários maliciosos de determinar o conteúdo do pacote e de injetar pacotes falsos para a WLAN.

Dantu, Clothier e Atri (2005, p.5) completam dizendo que:

Um dos problemas fundamentais para ser resolvidos considerando segu-rança de rede é aquela autenticação e autorização. Uma autenticação estabelece uma identidade genuína do dispositivo ou usuário que está desejando entrar em uma rede sem fio. A autorização determina que qualquer usuário autenticado ou dispositivo, está apto para juntar-se a rede.

2.3.1 Protocolo WEP

Segundo Tanenbaum (2003, p.586), com a ativação do protocolo WEP (Wired Equivalent Privacy), cada dispositivo dispõe de um código secreto que é compartilhado com o ponto de acesso. Não há especificação deste padrão de como esses códigos devem ser distribuídos aos dispositivos. O código secreto poderia ser pré-inserido pelo fabricante, como trocados com antecedência pelo ponto de acesso. Então haveria possibilidade tanto do ponto de acesso como o dispositivo do usuário, permitir a escolha de qual código secreto utilizar, perfazendo uso de uma chave pública de outro dispositivo, após estabelecer conexão com o ponto de acesso, os códigos podem durar um bom tempo, sendo meses ou anos. O protocolo de criptografia utilizado pela WEP baseia-se no algoritmo RC4 o qual foi desenvolvido por Ronald Rivest.

Segundo Keeratiwintakorn e Krishnamurthy (2005, p.4), pelo fato do protocolo WEP utilizar-se do algoritmo RC4 como base para criptografar de seus pacotes, ela possui várias falhas devido ao mal planejamento do projeto e também pela fraqueza do algoritmo RC4. Muitas interfaces de rede 802.11 e estruturas implantadas, teriam que migrar total-mente à um novo padrão de protocolo de segurança à um custo oneroso. Visando suporte legado as implementações, os protocolos de criptografia TKIP (Temporal Key Integrity Protocol) e Michael ofereceram de imediato diversas correções de segurança enquanto utiliza-se o hardware existente em infraestruturas de redes que já foram implantadas.

(22)

21

Na Figura 3 é demonstrando como ocorre o processo de criptografia no protocolo de segurança WEP.

Figura 3: Esquema do protocolo de segurança WEP

Fonte: Maia (2003, p.1)

2.3.2 Protocolo WPA

Dantu, Clothier e Atri (2005, p.5), uma vez que as vulnerabilidades com WEP foram identificadas, houve um trabalho em conjunto para desenvolver um novo protocolo de segurança para redes sem fio. O resultado desse desenvolvimento foi o surgimento do protocolo IEEE 802.11i, conhecido como WPA (Wi-Fi Protected Access). Para priorizar a aceitação do WPA, um consorcio de empresas envolvidas no setor de redes sem fio foi criado, chamando-se de Wi-Fi Alliance e procurou-se fazer um subconjunto de protocolos de criptografia para serem aplicados sobre esse novo protocolo de segurança ainda em desenvolvimento, o IEEE 802.11i. Ambos protocolos, WPA e IEEE 802.11, receberam dois modos de operação, sendo um deles para pequenos escritórios e residências e outro para médias e grandes empresas, tais modos chamados respectivamente de PSK (Pre-Shared Key) e Enterprise.

Segundo Eissa, Ali e Abdel-Latif (2010, p.3), o grupo tarefa 802.11i desenvolveu uma série de capacidades para resolver os problemas de segurança das WLANs. Para acelerar a introdução de forte segurança em WLANs, a aliança Wi-Fi anunciou o projeto Wi-Fi Protected Access (WPA) como um novo protocolo de segurança padrão. WPA tornou-se um conjunto de mecanismos que elimina a maioria dos problemas de segurança do protocolo WEP. Baseando-se no estado corrente do protocolo 802.11i (WPA) houve uma evolução para o WPA2 que manteve retro compatibilidades. O 802.11i foca em três

(23)

22

principais áreas de segurança sendo-as: autenticação, gerenciamento de chaves e privacidade na transferência de dados.

O processo de autenticação no protocolo WPA-PSK é demonstrado na Figura 4. Figura 4: Esquema de autenticação do protocolo WPA-PSK

Fonte: H3C (2010, p.1)

2.3.3 Protocolo WPA2

Segundo Burns (2004, p.1), as funcionalidades no IEEE 802.11i e WPA2 são virtualmente idênticas. As duas funcionalidades mais importantes além do WPA tornar-se padronizado através do 802.11i/WPA2 são: pré-autenticação, o qual ativa velocidade na segurança de roaming sem notar latência no sinal; e o uso da cifra CCMP (Counter-Mode/Cipher Block Chaining Message Authentication Code Protocol) no lugar do TKIP. CCMP é baseado na cifra AES (Advanced Encryption Standard). O AES produz um nível alto quanto a privacidade de dados requerido por algumas empresas, agências governamentais e outras organizações. O suporte ao CCMP é obrigatório em ambas especificações 802.11i e WPA2, a pró-autenticação é opcional para ambas.

Doreste, Homem e Martins (2013, p.5) dizem que:

O protocolo CCMP (Counter-Mode/Cipher Block Chaining Message Authentication Code Protocol) é o responsável pela integridade e confi-dência no WPA2. Ele utiliza o novo padrão para criptografia simétrica AES (Advanced Encryption Standard) que trabalha com blocos de 128 bits e, no caso do 802.11i, chaves de 128 bits. O CBC-MAC (Cipher Block Chaining Message Authentication Code) é responsável pela integridade dos quadros [...]

Sakib et al. (2011, p.2), uma das maiores mudanças introduzida com o protocolo WPA2 é a separação entre a autenticação de usuário e aplicação da privacidade e integridade

(24)

23

de mensagens, proporcionando assim uma arquitetura de segurança mais escalável e robusta para redes domésticas e corporativas com mesmo valor.

Doreste, Homem e Martins (2013, p.5) demonstram na Figura 5 como é executado o processo de criptografia do protocolo AES-CCMP.

Figura 5: Esquema do protocolo de criptografia WPA2-PSK AES-CCMP

Fonte: Doreste, Homem e Martins (2013, p.5) Tabela 1: Protocolos de segurança em Redes Sem Fio

Modo

Segurança

IEEE 802.11

WPA

WPA2

Pessoal

Nível de Sessão

WEP

PSK

Nível de Pacote

WEP

TKIP/Michael

AES-CCMP

Empresarial

Nível de Sessão

WEP

IEEE 802.1X

Nível de Pacote

WEP

TKIP/Michael

AES-CCMP

Fonte: Adaptado de Keeratiwintakorn e Krishnamurthy (2005, p.5)

Como Keeratiwintakorn e Krishnamurthy (2005, p.5) descrevem, atualmente há três protocolos de segurança para redes sem fio, sendo estas: WEP, WPA e WPA2. Para funcionar a troca de chaves em cada protocolo, eles possuem protocolos de criptografia que devem ser definidos no momento da configuração de um ponto de acesso, onde cada protocolo criptográfico têm suas características únicas, que são demonstrados na Tabela 1.

2.3.4 Modo PSK

Dantu, Clothier e Atri (2005, p.4), no modo pessoal, existe uma chave comparti-lhada entre o ponto de acesso e os dispositivos ou usuários desejando autenticar-se com o ponto de acesso. Mas ao invés de usar essa chave diretamente como base para a criptografia

(25)

24

como ocorre no protocolo WEP, a chave é usada para permitir a entrada do dispositivo na rede e assim uma nova chave, sendo esta única para cada usuário ou dispositivo, é gerada para propósitos de criptografar os dados.

Segundo Keeratiwintakorn e Krishnamurthy (2005, p.5), o modo pessoal favorece usuários domésticos e de pequenas empresas pelo fato de não necessitar de servidores de autenticação, portando aumentando a segurança para usuários não empresariais.

Segundo IEEE (2009, p.1), a versão final do protocolo 802.11n foi publicado oficialmente na data de 29 out. 2009, especificações para este padrão anteriores a essa data, eram considerados rascunho e funcionalidades em fase de testes, por base em tal não há motivos para prestar retro compatibilidade com padrões anteriores ao 802.11n.

2.3.5 Modo EAP

Dantu, Clothier e Atri (2005, p.4), WPA e WPA2 configurado e funcionando no modo empresarial, manuseia a autenticação através do padrão desenvolvido para controle de admissões para uma rede no qual foi publicado como o padrão IEEE 802.1X. Este padrão 802.1X não é exclusivamente de uso para redes sem fio e pode ser tranquilamente aplicado em qualquer rede ponto-a-ponto e VLANs (Virtual LANs).

De acordo com Sakib et al. (2011, p.3):

A autenticação no modo Enterprise depende do padrão de autenticação IEEE 802.1X. Os principais componentes são o suplicante (cliente) que ingressa na rede, o autenticador (o AP serve) fornecendo controle de acesso e o servidor de autenticação (RADIUS) fazendo as decisões de au-torização. O autenticador (AP) divide cada porta virtual em duas portas lógicas: uma para o serviço e outra para a autenticação, constituindo o PAE (Port Access Entity). [...]

Neste modo, a autenticação pode ser executada de diversas maneiras que são elas: Certificados TLS (Transport Layer Security), Nome de usuário e senha através de um portal captivo, o mac address identificado como nome de usuário ou somente uma senha. Nem todos os equipamentos de rede sem fio possuem esses métodos de autenticação via este padrão.

(26)

25

3 SEGURANÇA MODO EAP

Neste Capítulo abordaremos sobre funcionamento do protocolo IEEE 802.1X, protocolo e servidor RADIUS, e bases de dados que são suportados por um software que implementa e agrega novas funcionalidades sobre o protocolo RADIUS.

3.1 802.1X

Dantu, Clothier e Atri (2005, p.4), o 802.1X propõe uma solução pelo qual um suplicante é autenticado por meio de um servidor de autenticação. Em termos de WLAN no modo infraestrutura, o suplicante é usualmente o dispositivo sem fio ou usuário, o autenticador é o ponto de acesso com o qual o dispositivo ou usuário deseja comunicar-se, e o servidor de autenticação é um dispositivo tal como um servidor de autenticação, autorização e credenciais (AAA) ou um autenticador remoto que dispõe um serviço de discagem de usuário (RADIUS).

O processo de autenticação 802.1X é demonstrada na Figura 6. Figura 6: Autenticação 802.1X

Fonte: Lehembre (2005, p.8)

(27)

26

[...] é um protocolo padrão IEEE para controle de acesso de redes com base em portas (PNAC). Ele faz parte do grupo de protocolos de rede 802.1. Além disso, ele prevê mecanismos de autenticação para dispositivos que desejam se anexar a uma LAN ou WLAN. A IEEE 802.1X define o encapsulamento do Extensible Authentication Protocol (EAP) sobre IEEE 802, que é conhecido como "EAP over LAN"ou EAPOL. Qualquer computador que se conecta à rede deve primeiro fornecer informações de autenticação antes de ser permitido na rede.

Segundo Microsoft (2012, p.1) complementa dizendo que:

A autenticação IEEE 802.1X fornece uma barreira de segurança adicional para sua intranet que pode ser usada para evitar que computadores convidados, invasores ou não gerenciados que não podem executar uma autenticação bem-sucedida conectem-se à sua intranet. Pelo mesmo motivo que os administradores implantam a autenticação IEEE 802.1X para redes com fio IEEE 802.3 - segurança avançada - os administradores de redes querem implementar o padrão IEEE 802.1X para ajudar a proteger suas conexões de rede sem fio. Da mesma forma que um cliente de rede com fio autenticado deve enviar um conjunto de credenciais para serem validadas antes de poder enviar quadros pela intranet de Ethernet com fio, um cliente sem fio IEEE 802.1X também deve executar a autenticação antes de poder enviar tráfego pela sua porta do ponto de acesso (AP) sem fio e através da rede.

3.2 RADIUS

Segundo GNU (2009, p.1) RADIUS é:

[...] um servidor remoto para autenticação de usuários e contas. É de uso primário de provedores de serviço de internet, como também pode muito bem ser utilizado em qualquer rede que precisa de serviço de autenticação e contas centralizado para suas estações de trabalho.

Rigney et al. (2000, p.3), um servidor de acesso a rede opera como um cliente do RADIUS. O cliente é responsável por passar informações do usuário para determinados servidores RADIUS que foram designados, e então age baseado na resposta que é retornada. Servidores RADIUS são responsáveis por receberem pedidos de conexões de usuários, autenticando-os, e então retornando toda configuração necessária para o cliente e assim encerrando o serviço de entrega ao usuário. Um servidor RADIUS pode agir como um cliente proxy para outros servidores RADIUS ou outros tipos de servidores de autenticação.

Segundo Geier (2012, p.1), os servidores RADIUS são comuns em redes empresa-riais por oferecer contas, autorização e autenticação (AAA) centralizados para controle de acesso. Mas servidores RADIUS também podem ser muito úteis em pequenas e médias redes para ativar a autenticação 802.1X e aumentar a segurança e controle de quem acessa a rede sem fio configurada em WPA2-EAP.

(28)

27

Vieira (2011, p.1) afirma que um servidor RADIUS:

[. . . ] é o host que validará o pedido do NAS. A resposta do pedido de autenticação pode ser positiva (Access-Accept) acompanhada da tabela de parâmetros de resposta ou negativa (Access-Reject) sem nenhum parâmetro. Nas respostas positivas (Access-Accept) os parâmetros de resposta são usados para orientar o NAS de como tratar o cliente. Numa rede wireless, nos parâmetros podem constar por exemplo, o tempo máximo de conexão permitida, ou a chave de criptografia que deverá ser usada no canal de comunicação entre o cliente e o NAS.

Vieira (2011, p.1) ainda afirma que o serviço é:

[. . . ] amplamente usado em provedores de acesso a internet. No Brasil por exemplo, a Oi (empresa de telecomunicações) usa RADIUS no seu produto ADSL chamado Velox. No sistema Velox, o cliente inicia um pedido de conexão via protocolo PPPoE, um roteador Cisco série 7000 atende o pedido e envia o nome de usuário e senha para o servidor RADIUS (localizado num datacenter no Rio de Janeiro), o RADIUS por sua vez confere as credenciais em seu banco de dados e retorna para o roteador se o cliente pode se conectar ou não. Se a resposta for positiva, o cliente receberá um IP público e poderá navegar, caso a resposta seja negativa, o acesso é negado.

3.2.1 FreeRADIUS

Segundo Freeradius (2015a, p.1), o servidor FreeRADIUS é um serviço para unix e sistemas operacionais como o unix que permite configurar um servidor do protocolo radius, o qual permite ser usado para Autenticação e Contagem de vários tipos de acesso a rede. Para usar o servidor é necessário configurar corretamente o cliente, isso permitirá que possam se comunicar, incluindo servidores terminais, Switches Ethernet, pontos de acesso sem fio ou um computador com um aplicativo que emule a função de radius cliente.

Segundo Walt (2011, p.23), o FreeRADIUS é um projeto de código fonte aberto que é rico no quesito de suporte a funcionalidades implementado sobre o protocolo RADIUS além de possuir várias melhorias. Comunalmente quando as pessoas referem-se ao FreeRADIUS, tipicamente estão falando do software servidor que é o componente principal desta suíte chamada de FreeRADIUS.

Segundo Freeradius (2015b, p.1), como uma excelente suíte RADIUS, tem incluído como um pacote padrão para diversos sistemas operacionais, como pacotes binários e seu código fonte disponível para compilar em praticamente qualquer arquitetura de computador. Implementação em ambientes de produção, incluí instalações de grande escala suportando múltiplos servidores AAA com mais de dez milhões de usuários e milhões de requisições por dia. Também suporta requisições de proxy, balanceamento de carga e tolerância a falhas, como também habilidade para acessar vários tipos de bancos de dados. Diferentes

(29)

28

classes de autenticação que podem ativar gatilhos de acesso de diferentes bancos de dados de autenticação e autorização, e os registros de contagem podem ser simultaneamente gravados em múltiplos diretórios e bancos de dados.

A Figura 7 demonstra o conceito básico de funcionamento do FreeRADIUS onde há interação entre o cliente, ponto de acesso e o servidor de RADIUS, o ponto de acesso intermedeia a comunicação entre o cliente e servidor FreeRADIUS.

Figura 7: Conceito base do FreeRADIUS

Fonte: Cisco (2017, p.1)

3.3 MariaDB

Segundo Mariadb (2017, p.1), o MariaDB transforma dados em informação estru-turada em uma vasta de lista de aplicações, desde informações bancárias até websites. É um substituto melhorado do MySQL, onde seu desenvolvimento é em código fonte aberto e proporcionando um software de banco de dados relacional que provê uma interface SQL para gerir dados.

Segundo Mariadb (2017, p.1), afirma que o banco de dados é utilizado por sua agilidade na manipulação de dados, é escalável e robusto, possui um ecossistema rico de

(30)

29

motores de armazenamento e muitas outras ferramentas versáteis para diversos tipos de usos.

3.4 LDAP

Segundo Oliveira (2017, p.1), o LDAP (Lightweight Directory Access Protocol) é um protocolo que estabelece uma persistência de dados de forma organizada perfazendo uso de um esquema de diretórios hierárquicos o qual está definido na especificação X.500. O LDAP teve origem na Universidade de Michigan contando com o apoio e contribuição de pelo menos 40 empresas.

Junior (2008, p.3) complementa dizendo que: Na informática tudo que se precisa de organização utiliza o principio de diretórios, sistemas de arquivos, protocolos de transferência de arquivos, sistemas de armazenamento WEB, banco de dados e até mesmo o editor de registro do MS-Windows, ou seja, seu conceito é usado por tudo que se precise de organização, mas apesar de serem organizados em forma de diretórios eles não são um serviço de diretório, podendo a vir usufruir da utilização de um.

Segundo Junior (2008, p.3), o protocolo LDAP pode trabalhar de duas formas, centralizado e distribuído, ou seja concentrado as informações em um único local como também a mesma informação estando disponível em outros locais por meio de sincronização dos dados armazenados. A hierarquia deste protocolo é semelhante a uma árvore, onde começa-se pela raiz que é o domínio, passando pelos galhos os quais são a estrutura e chega-se nas folhas, os quais são os diretórios que armazenam as informações.

3.4.1 OpenLDAP

Segundo Trigo (2007, p.30), o OpenLDAP foi implementado sobre o protocolo LDAP onde ganhou novas funcionalidades como controle de acessos, suporte aos protocolo IP versão 4 e versão 6, camada de segurança utilizando SSL e TLS, replicação da base de dados e melhorias na performance enquanto há diversos resgate de dados.

Segundo Oliveira (2017, p.1), o OpenLDAP é:

[. . . ] O serviço é independente do sistema operacional que roda na máquina. Dessa forma, além de já vir incluso em diversas distribuições do Linux, ele também funciona em diversos outros sistemas, como Mac OS X, Microsoft Windows, BSD, Solaris, AIX, HP-UX e z/OS.

(31)

30

Ao se utilizar o SLDAP (servidor LDAP, máquina onde o OpenLDAP está instalado), como base para busca de informações, pode-se fazer com que todos os serviços e aplicativos da rede o usem para buscar as informações, de forma em que todos compartilhem uma única árvore. Fazendo com que todos os serviços da rede fiquem integrados a ele, facilitando muito a administração de redes de qualquer tamanho.

A Figura 8 demonstra a estrutura utilizando uma árvore para a analogia. Figura 8: Esquema exemplo de LDAP

Fonte: Adaptado de Oliveira (2017, p.1)

3.4.2 Active Directory

Segundo Rover (2012, p.1) sobre autenticação em domínios: “Hoje quando usamos um usuário para logar no domínio de nossa empresa, estamos utilizando um serviço de diretório e por consequência usando o Active Directory.”

Segundo Vidal (2006, p.1), o Active Directory é a implementação desenvolvida pela Microsoft e está disponível na versão para servidores do Windows. O uso típico é em conjunto a um controlador de domínio viabilizando a gerência de quais estações de trabalho são permitidos autenticar nesta rede, onde também utiliza-se a base de dados

(32)

31

do AD (Active Directory) para autenticação de outros serviços de rede como o 802.1X, portais de serviços aos usuários, autenticação de sistemas de uma organização.

Segundo Vidal (2006, p.1), os objetos comumente utilizados no AD são usuários, grupos de usuários e contas de computadores. Estes objetos guardam informações como usuário e senha, grupos que o usuário pertence, grupos que o computador pertence, se o computador está autorizado a autenticar usuários ou permitir que determinadas contas de usuário possam autenticar.

(33)

32

4 PROPOSTA DE MODELO DE

SEGU-RANÇA

Este capítulo abordará como será o cenário e a implementação que ocorrerá em cima dele baseado nos objetivos, sendo colocado em prática o uso da segurança WPA2-EAP que acessará o servidor RADIUS via protocolo 802.1X, onde o servidor de RADIUS acessará as bases de dados para autenticar as requisições de login que virão dos pontos de acesso e verificar se o grupo é permitido logar naquele AP.

4.1 Cenário de Implementação

O cenário a propor ocorrerá em um ambiente controlado para testes e não em produção. O cenário é composto por três Access Point (AP) sendo cada um nomeado respectivamente como AP1, AP2 e AP3. O AP3 está em uma rede remota e o acesso para o Servidor RADIUS será através de uma VPN (Virtual Private Network) L2TP/IPsec que estará configurada nos roteadores de ambas redes de testes. O roteador local será nomeado como R1 e o remoto como R2, entre os roteadores a conexão é a Internet e por ela que cruzará a VPN.

Os serviços de servidor RADIUS e as bases de dados estarão configurados dentro de máquinas virtuais a fim de utilizar menor quantidade de servidores físicos, além que facilita o gerenciamento desses serviços de forma ágil. Serão utilizados 3 máquinas virtuais para disponibilizar os respectivos serviços: MV (Máquina Virtual) 01 rodará o SO (Sistema Operacional) Arch Linux que disponibilizará os serviços FreeRADIUS e MariaDB; MV 02 rodará o SO Arch Linux e disponibilizará o OpenLDAP e por fim, a MV 03 rodará o SO Windows Server 2012 R2 edição Standard que disponibilizará o Active Directory.

Os SOs e softwares utilizados neste trabalho possuem licença gratuita e tem seu código fonte liberado para os usuários e desenvolvedores. O único SO não gratuito é o Windows Server 2012 R2 Standard, a licença para utilizar foi obtida no website do programa Microsoft Imagine no qual a Instituição de Ensino Superior UNIJUÍ possui convênio, isso possibilita que os alunos possam utilizar as licenças de SO do desenvolvedor Microsoft de forma legal perante o código penal de licenças de softwares.

O fabricante dos equipamentos de rede utilizados neste trabalho é a MikroTik que possui o SO RouterOS em seus roteadores e pontos de acesso. Os modelos dos equipamentos de rede são respectivamente: R1 hEX, R2 hEX Lite, AP1 hAP Lite, AP2 hAP Lite, AP3

(34)

33

hAP.

O computador hospedeiro das MVs é um Notebook que possui a seguinte configu-ração: SO Arch Linux de arquitetura 64-bits, microprocessador Intel de modelo I7-3630QM de 8 núcleos, 16 Gigabytes de memória RAM, disco rígido de 750 Gigabytes e interface de rede ethernet com velocidade de 1000 Megabits por segundo. O software de virtualização que será utilizado é o VirtualBox na versão 5.1.22, é desenvolvido pela Oracle.

Os dispositivos de redes estarão conectados a um Switch ethernet de 8 portas permitindo a comunicação entre os APs, roteadores e MVs. O AP3 acessará essa rede através da VPN presente no R1 para comunicar-se com a MV01, porém o acesso à Internet não trafega nessa VPN.

A Figura 9 demonstra como será o cenário de implementação. Figura 9: Cenário de Implementação

Fonte: Autoria Própria

A faixa de endereços utilizáveis da rede local será do 10.9.9.1 até 10.9.9.30 usando a máscara de sub-rede 255.255.255.224. Os dispositivos de rede irão utilizar os seguintes

(35)

34

endereços fixados em suas interfaces de rede conectados no Switch: R1 10.9.9.1, AP1 10.9.9.2, AP2 10.9.9.3, MV01 10.9.9.4, MV02 10.9.9.5, MV03 10.9.9.6, Notebook 10.9.9.7 e o AP3 por estar em uma rede remota, utilizará o 172.31.200.249 que está na faixa do 172.31.200.249 até 172.31.200.254 que utiliza máscara de sub-rede 255.255.255.248. As interfaces de rede que estão conectados a Internet do R1 e R2, utilizam endereço IP dinâmico que é fornecido pelo Provedor de Internet.

A faixa de endereços IP disponíveis aos usuários da rede local que conectarem nos AP1 e AP2 é do 10.9.9.10 até 10.9.9.30, na rede remota do AP3 é do 172.31.200.250 até 172.31.200.254.

O usuário poderá acessar a rede através das redes sem fio P1 e P2 que estão presentes respectivamente nos AP1 e AP2, caso o usuário vá ao local que está o AP3, poderá acessar a rede sem fio P3 desde que sua credencial esteja autorizada a logar a partir desse ponto de acesso. O dispositivo que o usuário pode usufruir para acessar a rede sem fio é desde um Smartphone, Tablet, Notebook e até computador que tenha interface de rede sem fio instalado.

4.2 Implementação

Esta Seção abordará como ocorrerá a implementação das bases de dados MariaDB, Active Directory e OpenLDAP, e também a configuração que será realizada no FreeRADIUS para ocorrer a verificação se o usuário é permitido aceder a rede sem fio a partir do AP que está conectando-se.

4.2.1 Implementação com Banco de Dados MariaDB

Após instalado o SO e o banco de dados MariaDB, foi executado um comando para efetuar a configuração inicial desse BD (Banco de Dados), sendo executado esse script a seguir: “/usr/bin/mysql_secure_installation”. Em seguida foi criado um usuário e senha para o FR (FreeRADIUS) aceder ao BD, e para finalizar o ambiente, foi criado a base de dados nomeado de “radius” e importado a estrutura de tabelas do arquivo “/etc/raddb/mods-config/sql/main/mysql/schema.sql” para dentro da base de dados recém

criada.

O próximo passo foi configurar o tipo e as informações de acesso do BD configurado anteriormente. As modificações foram feitas no arquivo “/etc/raddb/mods-available/sql”, a configuração utilizada está demonstrado na Figura 10.

(36)

35

de usuário, o atributo de senha, a operação de atribuição de valor e o valor que é a senha, isso é demonstrado na Figura 11. Os grupos são adicionados na tabela “radusergroup” que armazena o nome de usuário, o grupo que pertence e a prioridade desse usuário durante a autenticação, sendo demonstrado na Figura 12.

Figura 10: Configuração de acesso ao Banco de Dados

Figura 11: Usuários adicionados à tabela radcheck

O último passo é inserir as condições de autenticação na tabela “radcheckgroup” que consiste de um nome de grupo, o atributo do FR que será relacionado, a operação para esse atributo e um valor relacionado com a finalidade do atributo indicado.

A fim de cumprir um dos objetivos deste trabalho sobre permitir ou negar acesso através do ponto de acesso fonte, a tabela “radcheckgroup” será composto por dois tipos de informações, ação de rejeição da autenticação e quais pontos de acesso que o grupo é permitido autenticar. A informação que será inserida dará-se da seguinte forma: Nome_do_Grupo, o atributo do FR “Auth-Type”, a operação de atribuição representado por “:=” e o valor “Reject”; Nome_do_Grupo, o atributo do FR “NAS–IP–Address”, a

(37)

36

operação de diferença que é representado por “!=” e o valor que são os endereços IP versão 4 de cada ponto de acesso ao qual o grupo está autorizado efetuar o login.

Figura 12: Grupos e Usuários adicionados à tabela radusergroup

Portanto, para cada grupo é necessário inserir somente uma vez a informação de rejeição ao contrário de quais pontos de acesso são liberados. Para cada ponto de acesso que for liberado ao grupo, deverá ser inserido uma linha por AP, como por exemplo: o grupo A é permitido acessar a partir de três APs, para funcionar essa liberação, adiciona-se 3 linhas no BD sendo que cada uma representa unicamente um AP para aquele grupo, como demonstrado na Figura 13.

Figura 13: Condicionais configurados na tabela radgroupcheck

4.2.2 Implementação com o OpenLDAP

A implementação no OpenLDAP será semelhante ao do Active Directory em alguns pontos, pois utilizaremos o mesmo domínio (radius.rwx.moe) para a base de armazenamento dos dados, como também alguns atributos que existem em ambos serviços de diretórios LDAP. Assim como no AD, o OpenLDAP armazenará somente usuários e

(38)

37

grupos, os quais conterão as informações necessárias como nome de usuário, senha, nome do grupo, membros do grupo e os IPs que o grupo pode acessar.

A primeira etapa da implementação foi obter os arquivos do esquema de diretórios para o OpenLDAP, sendo utilizado os arquivos do projeto “Active Directory to OpenLdap” de autoria do dkoudela, onde disponibilizou os esquemas na plataforma GitHub. Esses esquemas estão adaptados para serem semelhantes a estrutura básica de grupos e usuários do Active Directory, proporcionando homogeneidade entre as bases LDAP.

A segunda etapa deu-se pela criação de um atributo e modificação de uma classe permitindo a implementação do objetivo deste trabalho. O atributo criado foi o “allowedIP”, o mesmo aparece no Capítulo 4.2 deste trabalho e executará a mesma função.

A classe modificada foi “groupOfNames”, havendo a necessidade de permitir que o atributo “allowedIP” possa ser usado, e foi removido a obrigatoriedade de haver um membro no

grupo no momento de sua adição.

Figura 14: Configuração de acesso ao OpenLDAP no arquivo ldap

Os arquivos de esquema LDAP principais são o “core.schema” e o “microsoftob-jectclass.schema”, no core foi efetuado as mudanças mencionadas no parágrafo acima. Já o microsoftobjectclass, contém as principais classes utilizadas no AD e o core utiliza algumas classes desse arquivo, isso permite que o AD e OpenLDAP possam ser homogêneos quanto

(39)

38

a utilização em forma de redundância de base de dados e balanceamento de carga, no sentido de usuários e grupos.

Na terceira etapa, efetuou-se a configuração de acesso ao OpenLDAP no arquivo ldap presente em “/etc/raddb/mods-available/”, essa instância foi chamada de “openldap”, de forma a permitir aceder o OpenLDAP devido a existência de uma instância padrão do tipo LDAP que foi configurada na Seção 4.2.3. Foram realizadas três alterações nas variáveis destacadas em negrito nesta instância na Figura 14.

A quarta e última etapa, foi criar um arquivo de texto possuindo dados para popular a base de dados com o propósito de efetuar os testes do Capítulo ??. Ainda nesta etapa, executou-se a configuração final do OpenLDAP no arquivo “slapd.conf”, sendo definido usuário e senha administrativo, e em qual diretório irá armazenar os dados efetivamente.

A Figura 15 demonstra um usuário e um grupo cadastrados na base de dados do OpenLDAP, o usuário está vinculado nesse grupo a fim de exemplificar como ficam registrados nesse BD.

Figura 15: Usuário e Grupo cadastrado no OpenLDAP

4.2.3 Implementação com Active Directory

No Active Directory utilizaremos a configuração padrão que é fornecida durante a instalação desse recurso no SO, o nome de domínio utilizado nesta implementação é radius.rwx.moe, a partir dele será possível acessar os dados que estão presentes, como usuários e seus grupos.

O arquivo de configuração do FR para acessar o AD (Active Directory) está disponível em “/etc/raddb/mods-available/ldap”, a partir da configuração padrão foi incluído as credenciais de acesso ao AD, endereço IP e porta de acesso ao servidor. Na seção user foi necessário definir a variável filter com o valor

(40)

“samaccountname=%{User-39

Name}” que permite a busca do nome de usuário de forma correta. E por fim, na seção group, houve necessidade de modificar três variáveis que são respectivamente o filter definido o valor “objectClass=group”, name_attribute com “allowedIP”, as respectivas alterações estão destacadas em negrito na Figura 16. Essa configuração demonstrada na Figura 16 está presente no arquivo ldap em “/etc/raddb/mods-available/”, e por ser a instância padrão, a mesma não é identificada como ocorrerá no Capítulo 4.2.2.

Figura 16: Configuração de acesso ao Active Directory no arquivo ldap

Para possibilitar o registro de endereços IPs nos grupos, foi necessário criar um atributo multi-valorado nomeado de “allowedIP”. Esse atributo foi criado dentro da classe de grupos a fim de não permitir que aconteça sobreposição caso o atributo existisse na classe de usuários. O atributo “allowedIP”, consiste de armazenar endereços IP versão 4 havendo o limite de 255 linhas, porém não possui um verificador que permita identificar que o valor a ser adicionado possa já existir nesse grupo ao qual está sendo editado. A Figura 17 demonstra como é utilizado o atributo.

O AD criptografa as senhas dos usuários impossibilitando que o FR tenha sucesso na verificação do login informado, pois o método de criptografia utilizado é proprietário da Microsoft e a mesma não informa qual método está implementado no AD. Porém a Microsoft criou um atributo chamado de “userPassword”, que guarda as informações nos formatos hexadecimal, decimal, octal e binário devido que o atributo utiliza o tipo de

(41)

40

dado Cadeia de Caracteres de Octetos.

O FR irá acessar o atributo “userPassword” do AD porque está definido essa variável na configuração de acesso visto na Figura 16, quando for requisitado esse atributo no AD, o mesmo passará a informação no formato de texto e não octal como é armazenado, isto é, o AD converte a informação antes de entregá-la.

Figura 17: Atributo allowedIP com dois IPs

Figura 18: Senha no formato de texto e hexadecimal do User2

(42)

41

Na Figura 18 podemos visualizar o valor do atributo “userPassword”, dessa forma o AD entrega como resposta à requisição RADIUS, e também podemos visualizar que para ser inserido o valor no atributo, é necessário que o texto esteja convertido para hexadecimal.

Portanto a partir da configuração feita anteriormente, a base de dados do AD está pronta para ser populada e acessada pelo FR.

4.2.4 Implementação com o FreeRADIUS

O FreeRADIUS é a etapa final das implementações que este trabalho propõe, sendo demonstrado as configurações necessárias para ativar a verificação de elegibilidade do cliente sem fio, quais arquivos de configuração são essenciais para essa funcionalidade e como devem ser executados. É de ressalta que o FreeRADIUS suporta o protocolo MS-CHAPv2 para criptografar a troca de informações entre o servidor RADIUS e o ponto de acesso, portando para prover esse suporte é necessário configuração adicional no dispositivo cliente bem como na configuração EAP do FreeRADIUS.

Os arquivos principais do FreeRADIUS são o “default” e “inner-tunnel” que estão disponíveis em “/etc/raddb/sites-available”. No “default” é adicionado os módulos que serão usados, configurações para ações específicas, e sua estrutura é em forma de seções permitindo que cada seja uma etapa do processo de AAA.

No arquivo “default” iremos adicionar os módulos e estrutura de verificação de elegibilidade, que constitui-se de condicionais baseados nos resultados obtidos a partir da execução dos módulos. E também neste arquivo é feito a solicitação de criptografia quando ativado a segunda fase de autenticação, isso ocasiona o envolvimento do arquivo "inner-tunnel"para processar o restante da solicitação do cliente.

No arquivo “inner-tunnel”, será adicionado somente os módulos com uma con-dicional que verifica se o usuário foi encontrado ou não nas bases de dados, isso previne processamento adicional caso o usuário seja encontrado no primeiro BD, pois não há necessidade de pesquisar nas demais bases de dados quando um nome de usuário e senha estão corretos.

Após as configurações de acesso aos devidos BD que transcorreram nos capítulos anteriores, permitirão o avanço na implementação do FR para configurar as condicionais e suas ações no arquivo “default”. As regras demonstradas na Figura 19 estão na seção de autorização, todo o inicio de requisição de login passará por esta seção. Não será feito somente a verificação se as credenciais informadas estão corretas, como será aqui a ocorrência de verificar se o usuário é permitido ou não autenticar a partir do ponto de acesso da requisição de login. As duas condicionais destacadas em negrito, permitem

(43)

42

que seja verificado a elegibilidade do usuário quanto ao ponto de acesso origem que tenta conectar-se.

Figura 19: Arquivo Default com as condicionais de acesso aos BD

Como visualizado na Figura 19, entre as condicionas são requisitados os módulos para acessar as bases de dados, sendo estes o “sql”, “ldap” (instância padrão) e “openldap” (a instância que pertence ao OpenLDAP), para o funcionamento correto, é necessário um link simbólico dos arquivos de configuração dos BD (sql e ldap) em “/etc/raddb/mods-available/” para “/etc/raddb/mods-enabled/”. Os arquivos estando disponíveis nesse diretório, torna-se possível o FR aceder esses BD e processar as requisições de autenticação.

O processo de verificação demonstrado na Figura 19 transcorre da seguinte forma: primeiro irá verificar no MariaDB se existe o nome de usuário informado, caso exista irá verificar a senha, caso esteja correto, buscará se existe um grupo para o usuário, caso exista, verificará se há ou não alguma regra específica para o grupo, havendo uma regra, a mesma será executada, se a condição for verdadeira, o login será rejeitado, caso contrário, será aceito, exemplo dessas regras para o grupo está na Figura 13.

Se no MariaDB não existir o usuário ou der falha no acesso, acessará o próximo módulo que é o ldap, o qual acessa o AD, e assim buscará a validade do login, caso as informações informadas estejam corretas, a condicional dará o valor falso devido que existe o usuário e executará as instruções que estão no else (se não) marcado em negrito e assim dará-se a verificação se o ponto de acesso origem está presente no grupo do usuário informado ou não, se a condicional dar verdadeiro, o login será recusado, caso contrário, será aceito. Exemplo de configuração dos IPs autorizados é demonstrado na Figura 17.

O AD retornando que o usuário não existe ou não estando acessível, então executará a última opção de base de dados que é o OpenLDAP, o processo de busca e verificação é

(44)

43

idêntico ao do AD que foi explanado no parágrafo anterior, porém possui a maioria dos dados diferentes do que estão armazenados no AD, isso permite que alguns usuários sejam acessíveis além do AD. A Figura 15 mostra em qual grupo o usuário está incluso e quais pontos de acesso ele pode autenticar-se, os mesmos estão destacados em negrito.

E por fim, no arquivo “inner-tunnel” foi adicionado duas condicionais que verificam se os módulos retornaram usuário não encontrado ou falha no acesso a base de dados sendo útil para fins de boas práticas no uso de recurso computacional. A importância disso é por causa da segunda fase de autenticação quando utilizado MS-CHAPv2, tornando-se necessário verificar novamente a senha do usuário. Deixa-se de verificar elegibilidade do usuário devido que esta checagem ocorreu na primeira etapa de autenticação. A Figura 20 demonstra como foi configurado na seção “authorize”.

Figura 20: Arquivo inner-tunnel

(45)

44

5 AVALIAÇÃO

DO

MODELO

PRO-POSTO

Este capítulo abordará sobre os testes que serão executados a fim de verificar o funcionamento das configurações que foram propostas por este trabalho, tendo ênfase na análise das condicionais que exercem a verificação de grupos relacionado ao IP do AP origem da requisição de autenticação.

O cenário de testes que será utilizado é o mencionado na Seção 4.1. Nele testaremos os grupos onde cada um possuirá um IP permitindo a autenticação. O GrupoA permitirá o AP1 (10.9.9.2), o GrupoB será o AP2 (10.9.9.3) e o GrupoC será o AP3 (172.31.200.249), caso haja necessidade de acessar mais de um AP, basta o usuário estar no grupo adicional que será permitido autenticar.

A Tabela 2 demonstra quais grupos os usuários pertencem, e não há restrição nos três BD a respeito que um usuário deve estar associado exclusivamente a um grupo, ele pode estar em nenhum grupo, e como pode estar em um ou vários grupos. A limitação de quantos grupos um usuário pode estar, não existe, porém recomenda-se que esteja somente nos grupos de necessidade, pois o tempo que levará a busca da relação entre Grupo, Usuário e IP do AP, é proporcional a quantidade de grupos armazenados nos BD.

Tabela 2: Grupos que os usuários pertencem GrupoA GrupoB GrupoC User1 X

User2 X

User3 X

User5 X X X

Teremos quarto casos de testes que serão executados da seguinte forma: o Teste 1 será um usuário presente em um único BD e que pertença a mais de um grupo. O Teste 2 será um usuário cadastrado em dois BD e sendo simulado falha de rede em um destes BD. O Teste 3 será um usuário tentando aceder a rede através de um AP que não está autorizado em seu grupo. E o Teste 4 será um usuário tentando aceder a rede mas seu nome de usuário não existirá nos BD.

O dispositivo cliente que será utilizando durantes os testes, é um Smartphone de marca LG e modelo G3 sendo a variante D855, o mesmo roda o SO Android na versão 7.1.2. A configuração de acesso às redes sem fio que utilizaremos serão: Método EAP: PEAP; Segunda Fase de Autenticação: MS-CHAPv2; Certificado CA: Não Validar;

(46)

45

Identidade: nome do usuário a ser testado; e Senha: é o nome do usuário. A Figura (ou anexo) demonstra a configuração mencionada.

5.1 Teste 1: Usuário cadastrado em um único local

Utilizaremos o usuário “user5” que está cadastrado somente no Active Directory e pertence aos grupos A, B e C, e acessará a rede a partir do AP3.

Figura 21: Log do FreeRADIUS referente a autenticação do User5

Como podemos visualizar na Figura 21, ao procurar pelo o usuário no MariaDB, não retornou resultados (linha 1), então passou-se ao próximo BD que é o AD (linhas 2 e 3), onde foi encontrado o usuário e executado a condicional de elegibilidade, respectivamente linhas 5 e 8. O “user5” autenticou-se com sucesso, pois a condicional na linha 12 retornou o valor falso, isso significa que o usuário está em um grupo que possui o IP do AP3. Os valores passados ao FreeRADIUS estão na linha 10 como “allowedIP” e “member”.

5.2 Teste 2: Usuário cadastrado em dois BD

Para este caso, utilizaremos o “user2” que está cadastrado no AD e OpenLDAP possuindo mesma senha e grupo que é o B. Para simularmos uma falha de rede no AD, desativaremos a placa de rede da MV02 tornando-a inacessível para qualquer serviço de rede que acessa essa MV.

O que podemos notar na Figura 22, é que o FreeRADIUS tentou acessar o AD quatro vezes seguidas como é visto na linha 5 através da informação “Reconnecting (4)”, e por não conseguir estabelecer a conexão, declarou como falha a execução do módulo

(47)

46

LDAP (linha 10), e por consequência, ocorreu cancelamento do processo de autorização (linha 12), demonstrando uma anomalia no funcionamento do FreeRADIUS com relação a este teste. O processo de busca não foi realizado devido a falha. A condicional (linha 11) entendeu como falha da seção de autorização, pois não aceitou o resultado fail como argumento válido para prosseguir a execução da autorização através desta condicional.

5.3 Teste 3: AP não autorizado para o GrupoC

No terceiro caso de teste, utilizaremos o “user3” que pertence ao GrupoC e está cadastrado no OpenLDAP, como dito anteriormente, o GrupoC só é permitido aceder a rede somente se o AP origem for o AP3 (172.31.200.249). Então o acesso será tentado a partir do AP1 (10.9.9.2) o qual no GrupoC não tem permissão.

O usuário não obteve sucesso na autenticação como é demonstrado na Figura 23, após ser encontrado no OpenLDAP vide linha 5, o valor da condicional que verifica o

(48)

47

grupo resultou em verdadeiro (linha 10), isso significa que o grupo do usuário não está elegível para conectar-se através desse AP. Ao final da figura vemos que o resultado da pesquisa diz que o usuário não faz parte de um grupo elegível para esse AP (linha 9) e como ação da condicional, a autenticação foi rejeitada (linha 11) como prevíamos para este caso de teste.

5.4 Teste 4: Usuário não encontrado

Em nosso último caso de teste, utilizaremos o nome de usuário “user4” que não está cadastrado em nossos BD, e com isso, a autenticação para esse usuário será rejeitada. O resultado esperado dos módulos é de usuário não encontrado.

A Figura 24 está demonstrado que o resultado esperado para cada módulo de BD, transcorreu na normalidade trazendo a mensagem de usuário não encontrado, ocorrendo nos três módulos que são: SQL, LDAP (AD), e openldap (OpenLDAP), respectivamente as linhas 6, 12 e 18 que mostram o resultado da execução do módulo (notfound). Os itens referentes ao nome de usuário utilizado nas buscas são vistos nas linhas 3, 4, 10 e 16. Na linha 20 é visto que a autorização foi rejeitada por não ter sido encontrado o usuário.