Protocolo 802.1x e Servidor de Autenticação FreeRadius.

Transcrição

1 Faculdade de Tecnologia Protocolo 802.1x e Servidor de Autenticação FreeRadius. Alunos: Anderson Mota, André Luiz da Silva, Misael Bezerra, Rodrigo Damasceno Kaji. GTI 5 Noturno Projeto de Redes de Computadores Prof. Dinailton José da Silva Junho 2015 Goiânia GO

2 ÍNDICE 1 INTRODUÇÃO O PROTOCOLO IEEE 802.1X PROTOCOLO POINT-TO-POINT (PPP) O PROTOCOLO EAP RADIUS PROCESSO AAA FREERADIUS REDE WIRELESS EAP-TLS (TRANSPORT LAYER SECURITY) EAP-TTLS (TUNNELED TRANSPORT LAYER SECURITY) PROTECTED EAP EAP_MD PEAP-MSCHAPv IMPLEMENTAÇÃO CONCLUSÃO REFERÊNCIAS BIBLIOGRÁFICAS... 39

3 1 INTRODUÇÃO Este documento faz uma descrição sobre os protocolos IEEE 802.1X que corresponde a um protocolo para controle de acesso de redes com base em portas, conceito dos protocolos PPP e EAP, breve introdução e descrição sobre servidor RADIUS, o FreeRadius e por fim a implementação 2 O PROTOCOLO IEEE 802.1X O protocolo IEEE 802.1X foi criada em Junho de 2001 pelo IEEE (Institute of Electrical and Electronic Engineers), sendo um protocolo padrão IEEE para controle de acesso de redes com base em portas (Port-based Network Access Control PNAC), fazendo parte do grupo de protocolos de rede Este protocolo tem a função de conceder permissão a um usuário que deseja acessar a uma rede graças a um servidor de autenticação, tendo como base portas de acesso. Este padrão identifica e autentica os usuários antes de permitir o seu acesso à rede. O protocolo provê mecanismos de autenticação para dispositivos que desejam se conectar a uma LAN ou WLAN. Está sendo uma solução cada vez mais aplicada utilizar o padrão 802.1X para controlar quem acessa uma rede, o 802.1X pode ser configurado para solicitar autenticação mútua entre o cliente e a rede, não havendo autenticação, as comunicações não são permitidas. O 802.1X trabalha com o protocolo EAP (Extensible Authentication Protocol) autenticando o cliente para a rede e a rede para o cliente, garantindo que ambos os lados se comuniquem com entidades reconhecidas. Todo computador que deseja se conectar a rede deve inicialmente fornecer informações de autenticação antes de obter permissão para acesso à rede. A autenticação IEEE 802.1X dispõe de um bloqueio adicional para a intranet, podendo ser utilizada no intuito de evitar que invasores, máquinas convidadas ou dispositivos não gerenciados obtenham conexão à internet de uma empresa sem antes passar pela autenticação. O protocolo 802.1X é projetado para atuar tanto em rede com fio quanto em rede sem fio. Exige uma infraestrutura de suporte, clientes nominais que suportem o 802.1X, switches, pontos de acesso sem fio, um servidor RADIUS e algum banco de dados de contas, como exemplo o LDAP ou Active Directory. 1

4 Um cliente, denominado suplicante (suplicant) realiza uma conexão inicial para um autenticador (authenticator), sendo um switch de rede ou um ponto de acesso sem fio. O autenticador será configurado para solicitar o protocolo 802.1X de todos os suplicantes e ignorará qualquer conexão de entrada que não estiver de acordo. O autenticador requere ao suplicante sua identidade, a qual ele enviará para o servidor RADIUS (authentication server) conforme a Figura 1. Figura 1: Infraestrutura operando com o protocolo padrão 802.1X Os elementos requeridos são: Software cliente, denominado suplicante, em cada ponto de extremidade; Pontos de acesso ou switches habilitados para o protocolo 802.1X, denominados autenticadores, mediando todas as comunicações efetuadas antes da atribuição do endereço IP; Servidor RADIUS (servidor de autenticação) gerenciando o processo AAA; A inteligência dessa solução está no servidor RADIUS e no suplicante, com o ponto de acesso ou switch simplesmente re-empacotando e distribuindo as informações. Geralmente a autenticação 802.1X é utilizada como uma forma de segurança avançada para redes com fio, porém as empresas começaram a utilizar o padrão IEEE 802.1X como uma forma de proteger suas conexões de rede sem fio. Isso 2

5 porque da mesma maneira que um cliente de rede com fio autenticado deve fornecer credenciais para serem validadas antes de ter autorização para enviar pacotes de dados pela intranet de Ethernet com fio, também um cliente de uma rede wireless IEEE 802.1X precisa executar a mesma autenticação antes de poder enviar pacotes de dados pela sua porta do ponto de acesso (Access Point) sem fio e através da rede. Mas para entendermos o que o padrão IEEE 802.1x é, e o motivo pelo qual devemos conhecê-lo, precisamos entender dois conceitos distintos que destacaremos a seguir, são eles: 3 PROTOCOLO POINT-TO-POINT (PPP) Este protocolo é mais comumente usado para acesso à Internet no método dial-up. O PPP é utilizado também por alguns provedores para autenticação de modem cabeado ou DSL, sob a forma de PPP sobre Ethernet. PPP é parte do protocolo Layer 2 Tunneling, parte indispensável da solução de acesso remoto seguro da Microsoft para o Windows 2000 e outros SO. O protocolo padrão IEEE 802.1X define um protocolo cliente e um controle de acesso tendo como base a autenticação de servidor restringindo os clientes não autorizados de se conectarem a uma rede local por intermédio de portas de acesso público. O servidor de autenticação realiza a autenticação de cada cliente conectado a uma porta do switch e atribui a porta a uma VLAN antes de permitir a disponibilização de todos os serviços oferecidos pelo switch ou LAN. O controle de acesso 802.1X habilita somente o tráfego do Protocolo de autenticação extensível sobre LAN (EAPOL) através da porta a qual o cliente está conectado enquanto o mesmo ainda não for autenticado. Depois de obter o sucesso na autenticação, o tráfego normal também pode passar por esta porta. A maioria das empresas desejavam mais segurança do que somente possuir nomes de usuários e senhas de acesso como forma de autenticação, de forma que um novo protocolo de autenticação, chamado EAP (Extensible Authentication Protocol), foi projetado. O EAP fica dentro do protocolo de autenticação PPP e fornece uma estrutura geral para muitos métodos de autenticação diferentes. 3

6 4 O PROTOCOLO EAP O 802.1x tem como base o EAP (Extensible Authentication Protocol). O protocolo EAP, que traduzindo significa Protocolo de Autenticação Estendível, é uma estrutura que promove a permissão a um usuário de se autenticar em um servidor específico na finalidade de receber mensagens provenientes do ponto de acesso. O servidor citado trabalha utilizando o protocolo RADIUS (Serviço de Autenticação Remota de Chamada de Usuário) e pode ser representado tanto pelo ponto de acesso quanto por uma outra máquina dedicada a este fim. O EAP foi originalmente desenvolvido para atuar com o protocolo PPP (Protocolo Ponto-a-Ponto), tendo o seu funcionamento definido como uma evolução deste protocolo. Com o uso do protocolo EAP para autenticação dos usuários a real identidade não é enviada antes do túnel de TLS codificado ser ativado. Após a identidade ser enviada, o processo de autenticação se inicia. O protocolo utilizado entre o autenticador e o suplicante é o EAP ou encapsulamento de EAP sobre a LAN EAPOL. O Autenticador re-encapsula as mensagens EAP para o formato de RADIUS e passa para o servidor de autenticação. São utilizadas por este protocolo quatro tipos de mensagens básicas durante a conexão, são elas: Requisição, Resposta, Sucesso e Falha. A primeira ação realizada para a conexão em uma rede sem fio que atua com o protocolo EAP é o envio de uma mensagem de Requisição para o ponto de acesso. Em seguida o ponto de acesso retorna um pedido da identidade que o suplicante (requisitante) possui. O suplicante envia a resposta de identificação, que ao receber, o ponto de acesso diretamente a envia para o servidor RADIUS. Este cria um desafio pelo qual o suplicante deve responder com o uso da senha que ele possui. Deste modo, caso a resposta seja a senha correta, será concedido o acesso à rede sem fio; caso contrário, o suplicante receberá uma mensagem de falha de conexão. Por fim, se o protocolo usado para encriptação for o WPA ou WPA2, então ocorre o acordo entre o suplicante e o ponto de acesso a fim de decidir os valores de chaves temporais que serão usadas durante a comunicação. A Figura 2 apresenta uma versão simplificada deste processo. 4

7 Em meio à autenticação, o autenticador retransmite os pacotes entre o suplicante e o servidor de autenticação. Quando é finalizado o processo de autenticação, o Servidor de autenticação prontamente envia uma mensagem de sucesso ou de fracasso. O autenticador por sua vez, abre a porta para o suplicante, depois de ter sucesso em sua autenticação, é concedido acesso a outros recursos da rede ao suplicante. Figura 2: Diagrama de Autenticação EAP com Servidor RADIUS Este modelo nos mostra uma característica que devemos levar em consideração que é o isolamento do servidor RADIUS: o suplicante e o servidor radius não se comunicam diretamente em nenhum momento; sempre deve haver a intervenção do ponto de acesso, garantindo uma maior segurança ao servidor, o que é de suma importância, pois ele contém informações referentes ao cadastro todos os usuários que são passíveis de acessar a rede. Além disto, o isolamento do servidor RADIUS é importante pois permite uma maior flexibilidade na hora da manutenção da rede, pois caso o esquema de segurança seja alterado, a manutenção será feita apenas na conexão entre o servidor e o ponto de acesso. Ainda sobre o EAP, existem diversas implementações do EAP, dentre as quais, duas delas se destacam: as que utilizam uma chave secreta para autenticação e as que utilizam criptografia assimétrica, onde as definiremos abaixo: 5

8 Chave Secreta: o suplicante e o servidor compartilham uma chave secreta. Esta chave é adicionada ao desafio recebido pelo suplicante e, então, é aplicada uma função resumo e ocorre o envio indireto para o servidor RADIUS. Este método não fornece ao suplicante autenticação do servidor e, portanto, está sujeito a ataques do tipo Man-In-The-Middle, além de ataques de dicionário. A implementação mais comum deste tipo é o EAP-MD5, que utiliza a função hash MD5. Criptografia Assimétrica: nesta implementação, existe uma autoridade certificadora que possui tanto a chave pública do servidor quanto a do suplicante. O servidor envia o desafio encriptado com sua chave privada para o suplicante, que o decripta com a chave pública adquirida na autoridade certificadora, encripta com a sua chave privada e reenvia para que o servidor RADIUS repita o mesmo procedimento. Caso a resposta do processo seja sucesso, a comunicação é garantida de ser imune a ataques de Man-In-The-Middle. O EAP-TLS (do inglês Transport Layer Security), que utiliza o algoritmo de criptografia assimétrica RSA é um exemplo deste tipo de implementação. 5 RADIUS Imaginemos a Internet sendo usada hoje sem nenhum tipo de controle, onde qualquer pessoa por exemplo, poderia acessar o da outra, realizar livremente transferências monetárias da conta bancária, realizar compras sem pagar, numa total desordem. Ao acessar uma máquina, um , um sistema de intranet, uma conta bancária, certamente passaremos por algum tipo de autenticação. A autenticação por login e senha é uma das formas mais conhecidas, no qual precisamos dizer ao computador quem somos e só então ele confere e verifica a nossa autenticidade, verifica quais são nossas permissões em determinado sistema e permite o acesso a tudo aquilo que temos direito. Todo esse processo é resumido em um protocolo chamado RADIUS. O RADIUS é um protocolo usado no propósito de disponibilizar acesso a redes utilizando a arquitetura AAA. Foi inicialmente desenvolvido para uso em serviços de acesso discado. Atualmente é implementado também em pontos de 6

9 acesso sem fio e outros dispositivos que concedem acesso autenticado a redes de computadores. O protocolo RADIUS é definido pela RFC O desenvolvimento do RADIUS se deu início em 1994, quando Steve Willens e Carl Rigney da Livingston Enterprise (hoje com o nome de Lucent) deixaram o código fonte do servidor RADIUS aberto para que outros desenvolvedores da Merit Networks, uma pioneira em criação de soluções para Internet na época, pudessem ajudar na construção do que hoje é um dos serviços mais utilizados na rede. O RADIUS foi desenvolvido para satisfazer uma necessidade de mercado da época. Naquele período, havia a necessidade de um produto que autenticasse, autorizasse e realizasse o acompanhamento e monitoramento do uso de recursos de rede utilizado pelos usuários. Após uma primeira reunião entre os desenvolvedores das duas empresas, se deu origem a uma versão muito superficial do RADIUS. Nos dias de hoje, tanto a Lucent quanto a Merit Networks disponibilizam serviços de Internet ao público baseado no RADIUS de forma gratuita. O protocolo RADIUS é baseado no modelo cliente/servidor, tendo do lado cliente o NAS (Network Access Server) e do lado servidor o servidor RADIUS. O utilizador, o NAS e o RADIUS trocam mensagens entre si quando o utilizador pretende se autenticar para dispor de um determinado servidor de rede. A mensagem RADIUS consiste em um pacote que contém um cabeçalho RADIUS com o tipo de mensagem, possuíndo ou não atributos associados à mensagem. Cada atributo RADIUS classifica uma parte de informação sobre a tentativa de ligação. Encontram-se atributos RADIUS para o nome de utilizador, para o tipo de serviço solicitado pelo utilizador, para a palavra passe do utilizador e para o endereço IP (Internet Protocol) do servidor de acesso. Os atributos RADIUS são usados no objetivo de transmitir informações entre clientes RADIUS, servidores RADIUS e proxies RADIUS. Quando um utilizador da rede quer utilizar um serviço ele envia os seus dados para o NAS. A responsabilidade do NAS é obter todos os dados do utilizador, que geralmente é o nome de utilizador e a respectiva palavra passe (no envio do NAS para o servidor a palavra passe é cifrada no intuito de prevenir possíveis ataques) e 7

10 enviá-los ao servidor RADIUS através de uma solicitação de acesso que é definida por Access Request. Este também possui a responsbilidade de processar respostas adquiridas do servidor RADIUS. O servidor ao receber uma solicitação de acesso realiza a autenticação do utilizador, enviando logo em seguida para o NAS a resposta: Access Accept se o acesso for aceito, Access Reject se o acesso for negado ou Access Challenge se for requerida uma nova confirmação. Depois da autenticação, são comparados e verificados alguns dados da solicitação de maneira que o servidor defina quais as permissões de acesso pode ser dado a este utilizador que foi autenticado. O servidor RADIUS também pode ser configurado em proxy. Neste modelo o servidor agirá como cliente redirecionando as solicitações de acesso para outro servidor, atuando como encarregado pela troca de mensagens entre o servidor remoto e o NAS. A Figura 3 descreve o funcionamento do protocolo RADIUS. Figura 3: Estabelecimento de uma sessão RADIUS O serviço RADIUS é amplamente utilizado em provedores de acesso a internet. A empresa Oi (empresa de telecomunicações) por exemplo, usa RADIUS no seu produto ADSL denominado Velox. Neste sistema, o suplicante inicia um 8

11 pedido de conexão via protocolo PPPoE, um roteador Cisco série 7000 atende este pedido e envia o nome de usuário e senha para o servidor RADIUS (localizado em um datacenter no Rio de Janeiro), onde o RADIUS por sua vez confere em seu banco de dados se há cadastrado aquele usuário e aquela senha e retorna para o roteador se o suplicante pode se conectar ou não. Caso a resposta seja positiva, o cliente irá receber um IP público e poderá navegar, já caso a resposta seja negativa, o acesso será prontamente negado. 5.1 PROCESSO AAA O RADIUS é implementado baseado em um processo chamado AAA (authentication, authorization, and accounting), que consiste em autenticação, autorização e acompanhamento/monitoramento do uso de recursos de rede pelo usuário. Embora o RADIUS ter sido implementado antes da arquitetura AAA ser elaborada, ele foi o primeiro protocolo tendo como base a arquitetura AAA que mostrou de fato suas funções às indústrias da época. Esta arquitetura monitora todos os passos do usuário, do início ao encerramento de sua conexão. Para melhor entendimento sobre o funcionamento deste processo, veremos abaixo os passos que o RADIUS percorre: Autenticação do usuário: processo que averigua se uma combinação de login e senha são válidas para o sistema. O login poderá ser uma conta de máquina, de usuário, um certificado digital, etc. Quando acessamos a Internet para navegar na web por exemplo, o método utilizado para a realização da autenticação é geralmente através de um login ID e uma senha. Autorização de serviços: é o próximo passo depois da identificação do usuário. O sistema verificará quais são os privilégios que o usuário terá naquele sistema. Geralmente em uma empresa existem diferenças de perfis de usuário, sendo alguns possuindo o acesso a todo o sistema e outros apenas alguns privilégios, onde a escolha do tipo de privilégio é definida pelo administrador da rede quando configurável ou pelo próprio sistema operacional que define as políticas padrões de acesso. Aqui o servidor AAA irá realizar uma série de processos e análises para saber 9

12 quem é quem, saber quais direitos e permissões de acesso o usuário possui. Acompanhamento/monitoramento dos serviços fornecidos: O processo de monitoramento/gerenciamento de recursos de rede usado pelo usuário é definido como accounting. O sistema acompanha cada passo dado por ele enquanto utiliza os serviços de rede. Este serviço é muito usado por provedores de banda larga que cobram do usuário por exceder o limite de banda, onde a cada n bytes ultrapassado é cobrada uma taxa a mais no valor mensal do usuário. Esse serviço também pode ser usado para justificar violações praticadas pelo usuário, uma vez que é registrado em um arquivo de log qualquer evento que aconteça durante a conexão entre o usuário e o servidor. 6 FREERADIUS Implementação de RADIUS modular, abundante em funcionalidades e opções e de alta performance. Esta implementação inclui cliente, servidor, bibliotecas de desenvolvimento e várias outras utilidades. Pode ser instalada em sistemas Machintosh e Linux. É licenciado sob a GPL, sendo um software livre e livre de custos, e é a base de vários servidores RADIUS comerciais no mundo. 7 REDE WIRELESS Há vários algoritmos de autenticação usados para o 802.1X. Alguns exemplos são: o EAP-TLS, o EAP-TTLS e o Protected EAP (PEAP). 7.1 EAP-TLS (TRANSPORT LAYER SECURITY) O protocolo EAP-TLS requer que o usuário e o servidor de autenticação tenham certificados para autenticação mútua. Embora o mecanismo seja muito forte, é necessário que a empresa que o implanta mantenha uma infra-estrutura de certificados para todos os usuários. 7.2 EAP-TTLS (TUNNELED TRANSPORT LAYER SECURITY) Algoritmo de autenticação implementado para fornecer autenticação tão forte quanto o EAP-TLS, mas não requer que cada usuário emita um certificado. Em vez disso, são emitidos certificados apenas para os servidores de autenticação. A 10

13 autenticação do usuário é feita por senha, mas as credenciais de senha são conduzidas criptografadas em um túnel estabelecido com base nos certificados do servidor. Após o servidor de autenticação visualizar que o usuário solicitou um pedido de autenticação, é enviado seu certificado para o sistema do mesmo (Figura 2). Figura 2: TTLS Certificado do Servidor Enviados para NAS O certificado do servidor de autenticação é utilizado para estabelecer um canal entre o usuário e o servidor (Figura 3). Figura 3: TTLS canal estabelecido Após o canal ser estabelecido, as credenciais podem ser trocadas de maneira segura entre o servidor e o utilizador, pois o canal criptografa todos os dados de uma forma segura. Esta fase é denominada autenticação interna (Figura 4). Figura 4: autenticação interna TTLS Com o EAP-TTLS, não é necessário criar uma nova infra-estrutura de certificados de utilizador. A autenticação do usuário é executada no mesmo banco de dados de segurança que já está em uso na LAN corporativa; Por exemplo, bancos de dados SQL ou LDAP, ou sistema de token. 11

14 7.3 PROTECTED EAP O Protocolo de Autenticação Extensível Protegido (PEAP) é da família dos protocolos EAP, e utiliza o TLS para criar um canal criptografado entre um cliente PEAP de autenticação (computador sem fio, por exemplo), e um autenticador PEAP, como um RADIUS ou serviço de autenticação da Internet. O PEAP não especifica um método de autenticação, mas garante segurança adicional para outros protocolos de autenticação EAP, como o EAP-MSCHAPv2, podendo operar pelo canal criptografado TLS adquirido pelo PEAP. O PEAP é utilizado como um método de autenticação para computadores clientes sem fio , mas não há suporte VPN (Rede Virtual Privada) ou outros clientes de acesso remoto. O PEAP não é um protocolo de criptografia, mas ele só autentica um cliente em uma rede assim como outros EAP. Existem dois estágios no processo de autenticação PEAP entre o cliente PEAP e o autenticador. O primeiro estágio configura um canal seguro entre o cliente PEAP e o servidor de autenticação. O segundo estágio provê a autenticação EAP entre o cliente EAP e o autenticador EAP_MD5 Modelo que permite a autenticação baseada em password, porem não há a cifragem do campo, portanto para redes wireless acaba se tornando muito insegura, fazendo com que os usuários adotem o uso do MS-CHAPv2 que é tão simples quanto o EAP_MD5 e mais seguro. Provavelmente seu uso seja necessário em situações de integração com outras plataformas e/ou soluções PEAP-MSCHAPv2 Modelo que permite a autenticação baseada em password, autenticação múltipla de computador e usuário, integração de autenticação camada 2 com login em rede Windows. É suportado em Linux, porém sua configuração é mais complexa. 12

15 8 IMPLEMENTAÇÃO Os arquivos serão divididos da seguinte forma: Instalação de servidor Radius (FreeRadius) e configurações para autenticação de clientes wireless com PEAP-MSCHAPv2 (usuário e senha); Instalação de um portal de autenticação HotSpot (Captive Portal), utilizando o NoCat. Instalação de ferramenta de gerencia gráfica para o FreeRadius (phpradmin) e autenticação com base de dados MySQL; Autenticação 802.1x utilizando certificado Digital; Integração da gerência do FreeRadius, MySQL, DHCP Server, OpenSSL, DNS, Apache e Nocat, com o WebMin. Será tratado a instalação do servidor e sua configuração de modo que possamos autenticar clientes de redes wireless, utilizando como credenciais de acesso o "usuário e senha", substituiremos o MD5 pelo MS-CHAPv2 devido a segurança visto que o MD5 não usa sessões cifradas entre o suplicante e o servidor FreeRadius, a MS não provê em seu cliente XP MD5 para Wireless, apenas Wired. Com este modelo de autenticação já é possível implantar uma rede wireless com um nível bom de segurança, permitindo uma base de usuários em arquivo texto, o qual migraremos futuramente para um banco MySQL e posteriormente para AD ou LDAP. Neste modelo de autenticação é possível realizar a configuração Single signon (SSO) e também passar como parâmetro a VLan ao qual o Cliente estará associado. A base de usuários inicialmente será em arquivo texto para simplificar o entendimento. 13

16 Figura 5: Diagrama lógico. Pré-requisitos Instalação do Ubuntu 6.06 LTS padrão, inserir o LiveCD se caso dispor de um e depois utilizar o script de instalação. Durante o tutorial, todas as linhas precedidas de # devem ser interpretadas como comandos executados diretamente no shell como root. Consideremos já concluída a instalação do Ubuntu 6.06 (padrão com Gnome). Vá para a pasta /usr/local/src, onde baixaremos os fontes: # cd /usr/local/src # wget ftp://ftp.freeradius.org/pub/radius/freeradius tar.gz # tar -zxvf freeradius tar.gz # cd tar freeradius Instale todas as ferramentas dpkg via apt-get como mostrado abaixo, pois elas não vem instaladas por padrão. # apt-get install dpkg* O OpenSSL vem na instalação padrão do Ubuntu, mas precisamos instalar algumas dependências, como: # apt-get build-dep openssl Para a construção dos pacotes.deb, os patches dpatch e o fakeroot : 14

17 # apt-get build-dep gcc # apt-get install dpatch # apt-get install fakeroot A criação dos pacotes.deb possuem o objetivo de corrigir as dependências mais facilmente com estas ferramentas. Do diretório fonte do freeradius (/usr/local/src/freeradius-1.1.7/), construir os pacotes.deb. Execute a seguinte linha: # dpkg-buildpackage rfakeroot Teremos algo parecido com isto: - dpkg-buildpackage: source package is freeradius - dpkg-buildpackage: source version is dpkg-buildpackage: source changed by Alan DeKok <aland@freeradius.org> - dpkg-buildpackage: host architecture i386 - dpkg-checkbuilddeps: Unmet build dependencies: dpatch (>= 2) autotools-dev libtool (>= 1.5) libltdl3-dev libpam0g-dev libmysqlclient15-dev libmysqlclient14-dev libmysqlclient-dev libgdbm-dev libldap2-dev libsasl2-dev libiodbc2-dev libkrb5-dev libperl-dev snmp libsnmp9- dev libsnmp5-dev libsnmp4.2-dev libpq-dev postgresql-dev libssl-dev - dpkg-buildpackage: Build dependencies/conflicts unsatisfied; aborting. - dpkg-buildpackage: (Use -d flag to override.) Vamos instalar as seguintes libs: # apt-get install autotools-dev # apt-get install libtool # apt-get install libltdl3-dev # apt-get install libpam0g-dev # apt-get install libmysqlclient15-dev # apt-get install libgdbm-dev # apt-get install libldap2-dev # apt-get install libsasl2-dev # apt-get install libiodbc2-dev # apt-get install libkrb5-dev # apt-get install libperl-dev # apt-get install snmp 15

18 # apt-get install libsnmp9-dev # apt-get install libpq-dev Agora execute novamente a seguinte linha: # dpkg-buildpackage -rfakeroot Então no diretório fonte do freeradius /usr/local/src/freeradius temos os seguintes pacotes.deb criados: - freeradius-krb5_ _i386.deb - freeradius-ldap_ _i386.deb - freeradius-dialupadmin_ _all.deb - freeradius-mysql_ _i386.deb - freeradius_ _i386.deb - freeradius-iodbc_ _i386.deb - freeradius-postgresql_ _i386.deb Instalar o freeradius, seguindo para o diretório /usr/local/src: # cd.. # dpkg -i freeradius_ _i386.deb Instalação com sucesso. Na instalação através do.deb temos os arquivos de configuração no diretório /etc/freeradius/ e o script para iniciar o radius que está em /etc/init.d não é radiusd e sim freeradius, então para iniciar o radius: # /etc/init.d/freeradius start Também será criado um usuário e grupo chamado "freerad". Primeiro instalaremos o FreeRadius já com suporte a MySQL. # yum -y install freeradius-mysql Os principais arquivos e os que utilizaremos são: 16

19 radiusd.conf : Principal arquivo de configuração, nele são configurados todos os parâmetros do servidor e também se habilita os módulos de AAA desejados (explicado acima); clients.conf : Configuração dos dispositivos que farão as consultas ao Radius (NAS), como o Access Point, switches..; users : Base de usuários, neste arquivo são cadastradas as credenciais Fase 1 dos usuários, onde o uso deste arquivo para cadastrar a base de usuários pode se tornar um sério risco de segurança caso seja mantida assim. Na fase 1 realizaremos um teste verificando o funcionamento do servidor, sendo o mesmo configurado de forma que aceite solicitações de autenticação da máquina local e buscar no arquivo "users" para autenticar o usuário. Em /etc/freeradius/ : editar o arquivo radius.conf e alterar as linhas abaixo, não alterando as outras. O # e o // nos arquivos de configuração são comentários. # indica a interface que o radius responde, coloque o ip da # interface desejada ou coloque "*" caso queira que responda # em qualquer interface bind_address = # indica a porta udp de escuta, pode usar também "*" port = 1812 # log para as autenticações log_auth = yes // log dos de autenticações e tentativas de autenticações log_auth_badpass = yes // log de login/senha incorretos log_auth_goodpass = yes // log de login/senha corretos Em /etc/freeradius : edite o arquivo users e adicione o usuário conforme indicado abaixo ao final do mesmo: # adicionar um usuário simples para teste teste Auth-Type := Local, User-Password == "teste" Em /etc/freeradius : edite o arquivo clients.conf e adicione o NAS conforme indicado abaixo ao final do arquivo: 17

20 # adiciona o localhost (NAS) permitindo que ele consulte o radius, outros # dispositivos também devem ser adicionados da mesma forma alterando # apenas os dados client { secret = testing123 // chave secreta que deve também ser configurada no NAS shortname = localhost // nome do dispositivo, que também deve ser o mesmo do configurado no dispositivo nastype = other // nastype é o tipo de NAS, existe alguns padrões de fabricantes já pré estabelecidos, pode ser consultado neste mesmo arquivo } Agora iniciaremos o RADIUS, que será feito com o seguinte comando padrão: # /etc/init.d/freeradius start Porém para visualizarmos os logs com maior facilidade iniciaremos no modo "debug" com o comando: # freeradius -X Desta maneira será exibido neste terminal todas as solicitações e respostas. Os logs também podem ser vistos em /var/log/freeradius/radius.log. Usando uma ferramenta de testes instalado junto com o pacote do "freeradius", o "radtest". Abra um novo shell e rode: # radtest teste teste : testing123 O "testing123" citado na linha acima é a chave secreta configurada no exemplo, e esta deve ser alterada conforme sua definição. O retorno deve ser algo tipo: Sending Access-Request of id 40 to port 1812 User-Name = "teste" User-Password = "teste" NAS-IP-Address = NAS-Port = 1812 rad_recv: Access-Accept packet from host :1812, id=40, length=20 18

21 Antes de prosseguir, vamos alinhar o entendimento sobre os mecanismos de autenticação mais comuns existentes. O IEEE 802.1x é um padrão do IEEE, que define mecanismos para autenticação em camada 2, dentre os protocolos que usa está o RADIUS (Remote Authentication Dial In User Service), que é um protocolo de autenticação AA(A). O 802.1x permite que utilizemos o EAP o qual nos possibilita uma variedade de métodos de autenticação, podendo optar por: EAP-TLS, EAP-TTLS, PEAP, EAP_MD5 ou PEAP-MSCHAPv2, apesar de ainda existirem outras como LEAP da cisco e outros. Para a autenticação será adotada a MSCHAPv2 em Windows. As boas práticas de segurança devem ser observadas, como senhas fortes, período de validade de senhas e certificados, etc. Até esta etapa estamos apenas provendo a autenticação. Após esta etapa, o controle do que o usuário pode ou não fazer deve ser implementado com cautela, sendo possível definir tudo o que o usuário pode ou não fazer após seu login. Fase 2 Nesta fase será configurado o radius para autenticar clientes wireless utilizando PEAP-MSCHAPv2 com criptografia WPA. PEAP-MSCHAPv2: Mecanismos de credenciais para autenticação, neste projeto piloto utilizando usuário e senha. WPA: Mecanismos que fornecem criptografia aos dados, utilizando TKIP (ou AES caso o equipamento suporte WPA2) como algorítimo de criptografia. Descrição: Rede com criptografia forte para os dados trafegados e utilizando controle de acesso via 802.1x provendo segurança a rede wireless. Com a rede implementada, será solicitado usuário e senha para acesso a rede. Este usuário só terá acesso a rede após a confirmação das credenciais, mantendo bloqueado em camada 2 o acesso caso não seja confirmada. Após a autenticação, os dados são criptografados usando WPA, que é fornecida automaticamente ao cliente. 19

22 Configurações: alterar os arquivos de configuração localizados em /etc/freeradius/ conforme segue abaxo: clients.conf client { // endereço do AP secret = testing123 // chave secreta shortname = DWL-3200AP // nome do AP nastype = other // tipo } eap.conf eap { # neste arquivo definimos os mecanismos de EAP suportados e como # deve o servidor se comportar para cada requisição, observe que # tratamos não apenas da autenticação entre suplicante e servidor, # mas também entre o NAS e servidores. # especificaremos que por padrão a autenticação será com TTLS default_eap_type = ttls timer_expire = 60 ignore_unknown_eap_types = no cisco_accounting_username_bug = no md5 { } mschapv2 { } } tls { } ttls { } peap { } private_key_password = whatever private_key_file = ${raddbdir}/certs/cert-srv.pem certificate_file = ${raddbdir}/certs/cert-srv.pem CA_file = ${raddbdir}/certs/democa/cacert.pem dh_file = ${raddbdir}/certs/dh random_file = ${raddbdir}/certs/random fragment_size = 1024 default_eap_type = md5 copy_request_to_tunnel = no use_tunneled_reply = no default_eap_type = mschapv2 20

23 Em radius.conf altere conforme segue abaixo: radiusd.conf prefix = /usr exec_prefix = /usr sysconfdir = /etc localstatedir = /var sbindir = /usr/sbin logdir = ${localstatedir}/log/radius raddbdir = /etc/freeradius radacctdir = ${logdir}/radacct confdir = ${raddbdir} run_dir = ${localstatedir}/run listen { ipaddr = * port = 0 type = auth } thread pool { start_servers = 1 max_servers = 4 min_spare_servers = 1 max_spare_servers = 3 max_requests_per_server = 0 } #Importando o arquivo com os clientes NAS, com permissão de autenticação $INCLUDE ${confdir}/clients.conf # abaixo estão os módulos de autenticação, autorização e contabilidade # que serão suportados. modules { # se utilizado apenas pap, usuário e senha passarão em texto puro, o # que não e nosso caso. pap { encryption_scheme = clear } chap { authtype = CHAP } # inclui o arquivo de configuração do EAP anterior $INCLUDE ${confdir}/eap.conf # suporta MS-CHAP para autenticação e também MS-CHAPv2 mschap { authtype = MS-CHAP with_ntdomain_hack = yes } mschapv2 { } 21

24 } # suporte a autenticação de usuários cadastrados em arquivo no caminho especificado files { usersfile = ${confdir}/users compat = no } # autoriza os seguintes módulos, obs MS-CHAP inclui v2 authorize { files mschap eap } # mecanismo de autenticação authenticate { Auth-Type MS-CHAP { mschap } eap } Em users, altere conforme segue: usuario1 User-Password == "senha1" # usuário e senha para o PEAP-MS-CHAPv2 Agora basta configurar o AP para autenticação 802.1x com as seguintes informações: Servidor radius = Porta = 1812 Chave secreta = testing123 //alterar a chave Configuração AP (Access Point) Utilizaremos o AP da TrendNet, porém pode-se utilizar qualquer AP que possua suporte a IEEE 802.1x. Segue abaixo os passos para configuração deste equipamento. 22

25 Figura 6: Configuração de endereço IP no equipamento. Configurar a rede wireless (SSID), desabilitando modo ª, neste caso usaremos somente a rede g. Devemos marcar a opção L2 isolation" (Figura 7), pois protege a rede contra o acesso direto de clientes wireless a outros clientes wireless. Figura 7: Marcando a opção Enable L2 Isolation 23

26 Selecionar o modo de autenticação WPA (Figura 8). Figura 8: Selecionar modo de autenticação WPA. Configurações para o padrão IEEE 802.1x (RADIUS) (Figura 9). Figura 9: configurando o servidor RADIUS. 24

27 Configuração cliente (Windows XP) Os requisitos básicos utilizados para a configuração no Windows XP servem para os demais sistemas operacionais que possuem suplicante 802.1x. Figura 10: Identificando a rede Dê duplo clique sobre a rede apontada na Figura 10 para adicionar o perfil desta rede. Clique em "Change Advanced Settings" e clique na aba "Wireless Network" conforme a Figura 11. Selecione a rede e clique em propriedades. Figura 11: Aba Wireless Networks em Wireless Network Connection Properties 25

28 O Windows XP ao identificar uma rede wireless com 802.1x habilitado, seleciona como credenciais de autenticação o EAP-TLS por padrão, porém como será utilizado usuário e senha, utilizaremos o EAP-PEAP-MSCHAPv2. Figura 12: Configuração das credenciais de autenticação. Conforme visualizado na Figura 12, devemos selecionar o WPA-TKIP (ou WPA-AES caso use WPA2) como mecanismo de criptografia para a associação com o Access Point. Na aba autenticação selecione EAP-PEAP, clique em propriedades e desmarque a opção validate server certificate (autenticando apenas com usuário e senha), selecione abaixo a opção EAP-MSCHAPv2 e clique em configurar desmarcando a opção Automatically use my Windows logon name and password 26

29 (and domain if any) para não ser utilizado o usuário e senha do Windows. Por fim, marque a opção Enable Fast Reconnect. Figura 13: Diagrama lógico (Wireless) Implementar rede wireless com controle de acesso, possuindo a seguinte característica: rede aberta para a conexão de qualquer usuário, porém com todas as conexões filtradas e controladas de maneira o acesso só será garantido ao usuário se ele abrir um navegador web que o redirecionará para uma página de autenticação, e a partir desta página o usuário poderá usar suas credenciais caso já possua ou se cadastrar. Instalação de pré-requisitos Será necessário: Ubuntu 6.06 LTS padrão, instalado sem DNS, micro com 2 interfaces LAN, 1 Access Point e 1 cartão de acesso wireless. Instalação Nocat O projeto NoCat converte um gateway de acesso em uma ferramenta de "Captive portal". Esta tecnologia se baseia em um firewall (iptables) que bloqueia toda conexão TCP/UDP a partir da rede local, capturando toda sessão http e redirecionado para um portal de login. Este portal de login recebe a proteção de uma sessão SSL, onde a partir do login no portal o NoCat aplica regras ao firewall permitindo acesso ao usuário conforme definições de uso. Para correto funcionamento do gateway será necessário algumas configurações adicionais e a instalação de serviços, conforme segue abaixo: Configuração das placas de rede Utilize o utilitário do FC6 ou "ifconfig": # system-config-network eth0 = internet (configure com ip dinâmico ou fixo de modo a ter acesso à internet); 27

30 eth1 = LAN (configure com ip fixo e sem gateway, no nosso caso ip = /24, se for alterado este endereço deve também ser alterado no dhcpd.conf) Servidor DHCP # yum install dhcp # cp /usr/share/doc/dhcp-3.0.5/dhcpd.conf.sample /etc/ (sujeito a atualizações, caso não encontre este diretório verifique a ver) # mv /etc/dhcp.conf.sample /etc/dhcpd.conf # vi /etc/dhcpd.conf (editar o arquivo conforme segue abaixo) ddns-update-style interim; ignore client-updates; subnet netmask { # --- default gateway option routers ; option subnet-mask ; option nis-domain "suarede.com.br"; option domain-name "suarede.com.br"; option domain-name-servers ; option time-offset ; # Eastern Standard Time range dynamic-bootp ; default-lease-time 21600; max-lease-time 43200; } Ao iniciar o serviço, o mesmo pode ser realizado com o script (rc.d"n") conforme comentado anteriormente: # /etc/init.d/dhcpd start Instalação servidor DNS (BIND) # yum install bind-chroot # yum install system-config-bind # chmod 755 /var/named/ # chmod 775 /var/named/chroot/ # chmod 775 /var/named/chroot/var/ # chmod 775 /var/named/chroot/var/named/ # chmod 775 /var/named/chroot/var/run/ # chmod 777 /var/named/chroot/var/run/named/ # cd /var/named/chroot/var/named/ # ln -s../../ chroot # chkconfig --levels 235 named on # system-config-bind (iniciar para criar as configurações padrões) Edite o named.conf conforme segue: # vi /var/named/chroot/etc/named.conf 28

31 Incluir as seguintes linhas: options { //outras opções// forward only; forwarders{serverdns1; serverdns2;}; }; Inicie o servidor: # /etc/init.d/named start Configuração do gateway Configurar o gateway para encaminhar os pacotes para a interface eth0, de modo a se tornar uma ponte de rede, sendo possível o acesso à internet de qualquer máquina conectada a interface eth1 configurada para ip dinâmico. # vi /etc/sysctl.conf Alterar a linha: "net.ipv4.ip_forward = 0" Para: net.ipv4.ip_forward = 1 Salve. # vi /etc/rc.d/rc.local Acrescentar a linha abaixo ao final do arquivo: iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE" Isso fará o nat para eth0. Desabilitar as funções de segurança, executar: # system-config-securitylevel Desabilitar o firewall e o SELinux e remover as configurações do iptables: # rm -r /etc/sysconfig/iptables* 29

32 Reiniciar o iptables: # /etc/init.d/iptables restart # yum install gnupg2 (ferramenta usada para criptografar) # perl -MCPAN -e 'install Digest::MD5' (mecanismo de autenticação) # perl -MCPAN -e 'install Net::Netmask' Instalação de pacotes adicionais Provavelmente o Digest-MD5 já estará instalado, de qualquer maneira será retornada a mensagem de que o UP já está instalado. Caso esta seja a primeira vez que é executado o instalador "perl MCPAN", muitas perguntas serão realizadas, mantenha-as como padrão, respondendo de acordo quando for questionado sua localização, mesmo se utilizar Proxy para web e FTP, no momento em que for requisitado entre com o(s) Proxy. Com estas configurações já será possível acessar a internet tendo como gateway nosso servidor, para isso confira inicialmente se os serviços estão marcados para inicialização automática: # system-config-services Verifique se estão marcados o http, bind (named) e dhcpd. # ping localhost Verifique se retorna ping, se não retornar configure o /etc/hosts acrescentando a linha: localhost loopback Reiniciar o servidor, conectar um micro na interface eth1, configurar para conseguir o endereço IP/DNS dinâmico, testar se os clientes da interface LAN podem acessar a internet, só passar para os próximos passos depois de concluir esta etapa. Instalação do NOCAT # mkdir /home/root/src (criar uma pasta para baixar as fontes) # cd /home/root/src # wget # tar zxvf NoCatAuth-nightly.tgz # cd NoCatAuth-nightly Alterando manualmente o Nocat para detectar firewall para kernel 2.6. # cd bin/ 30

33 # vi detect-fw.sh Substitua a linha: test X"`uname -sr cut -d. -f-2`" = X"Linux 2.4"; then Por: test X"`uname -sr cut -d. -f-2`" = X"Linux 2.6"; then Salvar. # cd.. (retorne para diretório principal dos fontes do Nocat) Criando o diretório principal para o Nocat e executando a instalação: # mkdir /usr/local/nocat (cria diretório padrão) # make PREFIX=/usr/local/nocat/gw gateway (instala o gateway) # make PREFIX=/usr/local/nocat/authserv authserv (instala o módulo autenticador) O Nocat já vem com uma chave para assinatura digital padrão, apague-a e crie uma nova: # rm -rf /usr/local/nocat/gw/pgp/trustedkeys.pgp # rm -rf /usr/local/nocat/authserv/pgp/trustedkeys.pgp # make PREFIX=/usr/local/nocat/authserv pgpkey Algumas perguntas serão feitas, responda conforme segue. Escolha DSA (opção 1); Escolha chave com 1024; Expira mantenha com 0, confirme nunca expira; Responda as perguntas de nome, , conforme necessários; Confirme suas opções. Será pedido uma senha, deixe este campo vazio, tecle enter apenas e novamente será pedido para confirmar, tecle novamente enter. A chave será gerada em alguns instantes, procure utilizar o micro normalmente, como acessar alguma página para que sejam coletados dados de forma aleatória para a geração da chave. Após a finalização da geração da chave copie-a para: # cp /usr/local/nocat/authserv/trustedkeys.pgp /usr/local/nocat/gw/pgp/ # cp /usr/local/nocat/authserv/trustedkeys.pgp /usr/local/nocat/authserv/ pgp/ 31

34 Altere o dono destes arquivos: # chown -R apache:apache /usr/local/nocat/authserv/pgp # chown -R apache:apache /usr/local/nocat/gw/pgp Altere as permissões: # chmod 755 /usr/local/nocat/authserv/pgp # chmod 755 /usr/local/nocat/gw/pgp Esta instalação do Nocat está utilizando o MySQL para armazenar os usuários e senhas, posteriormente pode-se utilizar outras bases para a autenticação, como servidor radius, ldap, arquivo texto e etc, para tanto iremos agora iniciar o MySQL, em services (system-config-services) marque para que o mysql seja iniciado no boot. Iniciar o mysql: # /etc/init.d/mysqld start Criar uma senha para o mysql: # mysqladmin password senha Criar o banco Nocat: # mysqladmin create nocat -p Ainda dentro da pasta principal dos fontes do mysql, copiar a base padrão do Nocat: # mysql nocat < etc/nocat.schema -p Entrar com a senha determinada anteriormente. Entrar no modo root no mysql: # mysql -u root -p (entrar com a senha) Dar privilégios para o usuário nocat, com senha nocatauth: mysql> grant all on nocat.* to nocat@localhost identified by 'nocatauth'; mysql> flush privileges; mysql> quit; Acessar o mysql com o usuário nocat e senha nocatauth. # mysql -u nocat -pnocatauth mysql> use nocat mysql> show tables; Você deverá visualizar as tabelas do nocat: mysql> quit O nocat está instalado,próxima etapa é configurá-lo. 32

35 Configurações do NOCAT Há dois arquivos de configuração do NOCAT, um está em /usr/local/nocat/gw/ e outro em /usr/local/nocat/authserv/, ambos com o mesmo nome "nocat.conf", portanto não podemos confundí-los. Em /usr/local/nocat/authserv/nocat.conf, alterar as seguintes linhas: HomePage // coloque a sua pagina inicial LocalGateway // endereço da interface da rede interna eth1 LocalNetwork // endereço de rede da interface da rede interna eth1, observe que LocalNetwork não aparece como opção, devemos acrescentar. DataSource DBI // marca a fonte para banco de dados... nosso caso mysql DataBase dbi:mysql:database=nocat // conector para mysql database nocat DB_User nocat // usuário do banco nocat, você deve alterar a gosto DB_Passwd nocatauth // senha do banco nocat, você deve alterar a gosto PGPKeyPath /usr/local/nocat/authserv/pgp // confira o endereço DocumentRoot /usr/local/nocat/authserv/htdocs No final do arquivo existe uma série de mensagens, em /usr/local/nocat/gw/nocat.conf altere as seguintes linhas: GatewayName Nome Gateway //entre com um nome para seu nocat GatewayMode Passive //no nosso caso como precisamos de nat somente o modo Passive. AuthServiceAddr ExternalDevice eth0 // pode ficar comentado, ele detecta sozinho InternalDevice eth1 // pode ficar comentado, ele detecta sozinho LocalNetwork /24 DNSAddr // importante é preciso utilizar o DNS no gateway, caso contrário poderá ter sites bloqueados na consulta de dns. IncludePorts // são as portas que ele aceitará serviços #ExcludePorts 25 // não use as duas opções simultaneamente, por isso comente esta linha PGPKeyPath /usr/local/nocat/gw/pgp DocumentRoot /usr/local/nocat/authserv/htdocs Configurações do APACHE (web-server) Inicialmente crie um novo certificado e chave para o "Apache", não utilizando o certificado padrão. Para isso utilizaremos o openssl, que já deve ter sido instalado com o SO, caso não tenha instalado, instale via yum: # yum -y install openssl Criar uma pasta ssl e siga nesta pasta os procedimentos abaixo para criar uma nova chave e assinatura para certificado: # openssl genrsa -out nocat.key 1024 # openssl req -new -key nocat.key -out nocat.csr 33

36 Criando um certificado assinado e os movendo para a pasta padrão do apache: # openssl x509 -days 365 -req -in nocat.csr -signkey nocat.key -out nocat.crt # mv nocat.crt /etc/pki/tls/certs/nocat.crt # mv nocat.key /etc/pki/tls/private/nocat.key Assim só há a necessidade de alterar o nome do arquivo de certificado e chave no arquivo de configuração no diretório /etc/http/conf.d/ssl.conf, conforme segue: Include conf.d/*.conf Include /usr/local/nocat/authserv/httpd.conf ServerAdmin admin@admin.br ServerName DocumentRoot "/usr/local/nocat/authserv/htdocs" ScriptAlias /cgi-bin/ /usr/local/nocat/authserv/cgi-bin/ <Directory "/usr/local/nocat/authserv/cgi-bin"> SetEnv PERL5LIB /usr/local/nocat/suthserv/lib SetEnv NOCAT /usr/local/nocat/authserv/nocat.conf # AllowOverride None # Options None # Order allow,deny # Allow from all </Directory> # vi /etc/httpd/conf.d/ssl.conf Edite este arquivo conforme segue: SSLPassPhraseDialog builtin SSLSessionCache shmcb:/var/cache/mod_ssl/scache(512000) SSLSessionCacheTimeout 300 SSLRandomSeed startup builtin SSLRandomSeed connect builtin SSLCryptoDevice builtin #SSLCryptoDevice ubsec SSLCertificateFile /etc/pki/tls/certs/nocat.crt SSLCertificateKeyFile /etc/pki/tls/private/nocat.key #SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire <Files ~ "\.(cgi shtml phtml php3?)$"> SSLOptions +StdEnvVars </Files> <Directory "/usr/local/nocat/authserv/cgi-bin"> SSLOptions +StdEnvVars </Directory> 34

37 Instalação do access point (AP) Figura 14: Diagrama lógico (Access Point) A instalação do Access Point deve ser implementada de maneira que permita o fácil acesso à rede wireless, então vamos configurá-lo de forma abera, sem restrição de acesso. Geralmente todos os equipamentos vem implementado desta forma de fábrica, mas de qualquer maneira consultar a documentação do fabricante. O gateway configurado até aqui é bem seguro quanto a permissão do acesso e controle de quais serviços baseados em portas tcp/udp podem passar, apesar de não ter nenhuma preocupação com a segurança em controlar o que um cliente desta rede acesse ou tente acessar outros micros no mesmo lado da lan. Para isso devem ser tomados alguns cuidados básicos: Inicialmente deve-se colocar um aviso orientando os usuários a utilizarem VPN caso acessem conteúdos críticos na página inicial. Geralmente todos os bons Access Points dispoem de recurso de "lan isolation", impedindo que um cliente wireless acesse outro (via acl). Esse recurso pode ser implementado no NoCat. Inserir um endereço de IP no Access Point em rede distinto do que está sendo publicado no DHCP, dificultará bastante o acesso. Pode-se restringir o acesso ao seu gerenciamento via rede wireless e também restringir o IP que pode acessar o gerenciamento em alguns equipamentos. 35

38 Esta medidas promovem a segurança do Access Point e do acesso indevido entre os clientes da rede. Configurações finais Para que o Nocat seja inicializado na sequencia correta durante o boot, use um "script" disponibilizado com ele. Copie da pasta /etc que está dentro da pasta onde estão os arquivos fontes do nocat (NoCatAuth-nightly/etc) o arquivo "nocat.rc" para a pasta /etc/rc.d/, deixando padrão em relação aos demais arquivos. Mudar seu nome para "rc.nocat", editar e alterar este arquivo conforme segue. # Edit the following line if you installed the # NoCat software somewhere else. # NC=/usr/local/nocat/gw/ Edite o arquivo /etc/rc.d/rc.local. No lugar que inserimos a regra para gateway, comentemos esta regra e acrescentar uma linha para carregar o script do nocat, pois seu objetivo da linha para encaminhamento era testar se a ponte de rede estava ok. Edite então o arquivo /etc/rc.d/rc.local, conforme segue: touch /var/lock/subsys/local #iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE /etc/rc.d/rc.nocat start O portal de acesso está concluido. Pode ser usado também para redes wired, caso encontre uma aplicação. O NoCat permite muitas configurações adicionais, como a liberação de alguns sites para navegação mesmo que os usuários não tenham sido logados. Login Esta é a tela inicial de Login (Figura 15), nela existirá um link para cadastro de usuário, onde estas podem ser totalmente customizadas, podendo inserir links para as páginas em que o acesso é liberado (o cadastro deverá ser feito no arquivo nocat.conf) e removendo o link para cadastro, etc. 36