Relatório Final de Estágio 2007/2008

Transcrição

1 Relatório Final de Estágio 2007/2008 Mestrado em Engenharia Informática Título: Estudo e Implementação de Serviços de Rede no Instituto Pedro Nunes Autor: André João Gaspar Ribeiro ajoao@ipn.pt ajoao@student.dei.uc.pt Orientadores: Eng. Nuno Pimenta IPN Dr. Mário Rela DEI Data: 14 de Julho de 2008 Entidade de Ensino: Departamento de Engenharia Informática Faculdade de Ciências e Tecnologia Universidade de Coimbra

2 Agradecimentos Este trabalho foi realizado dentro da equipa da Unidade de Serviços Informáticos e Comunicações (USIC) do IPNlis e foi aí que vivi durante todo o tempo do Estágio. A forma como fui recebido e tratado por todos os colegas, da USIC e das restantes unidades, foram excepcionais e resultaram num bem estar comum, que me motivaram bastante. Tenho de salientar a importância do trabalho em equipa, pois dadas as suas circunstâncias, seria impossível a sua implementação. Para além de não conhecer a infra-estrutura de rede e os seus serviços internos, a falta de experiência na área fez com que ocasionalmente necessitasse do suporte da equipa, que apesar da falta de tempo, sempre se disponibilizou quando foi necessário. Assim tenho um especial agradecimento aos meus colegas Bruno Teixeira, Carlos Ramos e orientador Nuno Pimenta. Durante a execução de uma das actividades, em que as dificuldades eram grandes, pedi auxilio ao Professor Jorge Granjal, que imediatamente se disponibilizou para me esclarecer dúvidas num problema no qual já tinha experiência. Fica aqui então a minha gratidão pela sua disponibilidade e paciência em me ajudar nas dificuldades que passei. Por fim agradeço ao meu orientador do DEI, Professor Dr. Mário Rela, que apesar de ter estado fora do país, nunca me abandonou e acabou por ser decisivo para a concretização deste Estágio. Relatório.Estágio.Final.odt Página 2/40

3 ÍNDICE RESUMO...5 INTRODUÇÃO...6 DESCRIÇÃO DOS ANEXOS...7 GESTÃO E PLANEAMENTO...8 MAPA DE GANTT PLANEADO...9 MAPA DE GANTT EXECUTADO...12 ACTIVIDADE 1 REDE WIRELESS...14 DESCRIÇÃO...14 IMPLEMENTAÇÃO DO SISTEMA...14 LOCALIZAÇÃO DOS AP'S...14 CONFIGURAÇÕES DOS AP'S...16 FUNCIONAMENTO GLOBAL...17 Utilizadores convidados...18 Utilizadores do openvpn...19 PÁGINA DE ADMINISTRAÇÃO DE TICKETS WIRELESS...20 SEGURANÇA...21 CONCLUSÕES E RESULTADOS...22 ACTIVIDADE 2 SERVIDOR DE IMPRESSÕES...24 DESCRIÇÃO...24 IMPLEMENTAÇÃO DO SISTEMA...24 CUPS...25 Autenticação dos utilizadores...26 PYKOTA...26 Problemas encontrados...28 AUTOMATIZAÇÃO DAS ESTATÍSTICAS DE IMPRESSÃO...29 CONCLUSÕES E RESULTADOS...29 ACTIVIDADE 3 MONITOR DE TRÁFEGO...31 DESCRIÇÃO...31 IMPLEMENTAÇÃO DO SISTEMA...31 NTOP...33 PMACCT...34 Crescimento da base de dados...34 BWStat...35 CONCLUSÕES E RESULTADOS...36 CONCLUSÕES FINAIS...37 REFERÊNCIAS...38 ACRÓNIMOS...40 Relatório.Estágio.Final.odt Página 3/40

4 Resumo Este documento serve para discriminar pedagógica e cientificamente, todo o processo de execução e implementação do trabalho de um Estágio do segundo ciclo de Engenharia Informática, realizado no IPNlis desde Novembro de 2007 até Julho de A sua escrita será o mais simples e objectiva possível e o seu público alvo poderá ser qualquer pessoa com formação superior em Engenharia, podendo no entanto ser facilmente legível por alguém com conhecimento na área de redes e telecomunicações. O projecto em causa é do âmbito de administração e manutenção de redes de comunicações, com o principal objectivo de criar novos serviços informáticos aos utilizadores de uma rede organizacional. É composto, por três actividades distintas, que apesar de se inserirem todas na rede informática do IPN, têm objectivos diferentes e que surgem numa iniciativa de proporcionar melhorias na qualidade do serviço prestado pela USIC aos utilizadores do IPN. O relatório contempla em primeiro lugar a definição dos objectivos de cada actividade, seguido da sua gestão e planeamento, o resumo do desenvolvimento de cada actividade e seus resultados. Em anexo estão presentes documentos de estudos, pesquisas de soluções a implementar, manuais de procedimentos e configurações de manutenção, e screenshot's de uma página de instruções de configuração, cada um referente a uma determinada actividade. Relatório.Estágio.Final.odt Página 4/40

5 Introdução A rede informática do IPN oferece actualmente uma variedade de serviços aos colaboradores dos diferentes laboratórios, segundo as necessidades de cada laboratório ou individualmente de cada projecto. Este trabalho criou novos serviços, até então inexistentes, o que permite oferecer mais valor interno ao IPN. Sendo assim, descreve-se de seguida cada actividade realizada, a sua motivação e os objectivos principais de cada uma: Actividade 1 Rede Wireless do IPN Motivação: No início do estágio, a rede Wireless do IPN era limitada apenas aos seus colaboradores e a sua cobertura era muito parcial. Objectivos: Alargamento do acesso à rede Wireless a convidados, através de chaves temporárias, de duração variável; expandir a rede Wireless a todo o IPN; manter em simultâneo, um acesso simples e seguro aos colaboradores do IPN. Actividade 2 Servidor de Impressões Motivação: O acesso ás impressoras partilhadas do IPNlis é livre aos seus colaboradores. É natural que haja laboratórios ou projectos, que imprimem mais do que outros, o que leva a distribuição de custos de manutenção das impressoras desproporcional. Objectivos: Implementar um sistema partilhado de impressoras na rede local, que contabilize em cada impressora, o número de impressões por utilizador; não deve impor nenhum limite à quantidade de impressões; deve apenas registar esses dados permanentemente para uma melhor racionalização de custos. Actividade 3 Monitor de Tráfego Motivação: O acesso à Internet a partir da rede do IPN, encontra-se por vezes lento devido à pouca largura de banda existente e/ou devido à utilização intensiva por parte dos seus utilizadores. Isto provoca alguma consternação a quem necessite da Internet para trabalhar. O aluguer da linha de acesso não é barata e é paga pelo IPN, não sendo racionalizada pelos diferentes laboratórios. Objectivos: Contabilizar o tráfego à entrada e à saída para o circuito externo, de ligação à Internet. Deverá registar os dados permanentemente por VLAN (cada unidade respectivamente) e permitir a sua visualização. Deve servir como ferramenta de estudo, para futuramente se classificar e definir prioridades de tráfego por tipo de serviço. Cada uma destas actividades consistiu em colocar um servidor em produção, que teve de ser instalado e configurado de raíz. Para tal, foram aproveitadas máquinas que não estavam a ser utilizadas no IPNlis. O SO a instalar em cada servidor pretende-se que seja open-source, nomeadamente Linux Gentoo, por ser adequado a ambientes de produção e por ser o mais usado na instituição. Também o restante software a instalar deverá ser aberto e com a possibilidade de ajustar novos desenvolvimentos à medida das necessidades. Como é normal na maioria das redes das organizações de hoje em dia, a rede do IPN trabalha com IPv4, pelo que em qualquer das actividades, toda a implementação e testes serão sobre esta versão de IP, não estando planeada ainda qualquer migração para o mais recente IPv6. Também em relação aos protocolos a usar em qualquer serviço, espera-se que seja o mais Relatório.Estágio.Final.odt Página 5/40

6 normalizado e standard possível, de modo a que a interoperabilidade entre qualquer sistema seja a melhor. De seguida será apresentada a gestão e o planeamento que todo o projecto teve em curso, dando a conhecer detalhadamente os passos efectuados para a sua realização. A descrição e desenvolvimento de cada actividade é dada numa secção dedicada para tal, seguindo-se as suas conclusões no final de cada uma. Seguem-se as conclusões globais de todo o trabalho realizado e no final do documento encontram-se as referências usadas e uma lista de acrónimos. Após a leitura deste relatório, é importante também ter um contacto com os anexos apresentados, pois foram documentos elaborados ao longo do projecto e representam uma mais valia na implementação da actividade a que se referem. Estão identificados com o número da actividade seguido do resultado esperado, conforme apresentado na proposta deste Estágio. Estes podem ter uma componente mais técnica, mas foram necessários para executar os trabalhos e também para deixar documentação sobre o que se implementou. Descrição dos anexos Estão presentes com este documento, os seguintes anexos: Anexo 1 - Estudo da rede Wireless inicial do IPN Anexo 2 - Análise de sistemas open-source de geração de chaves temporárias para redes Wireless Anexo 3 - Procedimentos e configurações de manutenção da rede Wireless Anexo 4 - Especificação de uma solução open-source para partilha de impressoras e contabilização de impressões Anexo 5 - Procedimentos e configurações de manutenção do servidor de impressoras Anexo 6 - Screenshot's da página Web de suporte à configuração das impressoras nos clientes em Windows XP e Linux Anexo 7 - Análise de soluções open-source para contabilização de tráfego IP Anexo 8 - Manual de procedimentos e configurações do servidor Traffic Monitor Anexo 9 - Backups & Updates de sistema dos servidores instalados Relatório.Estágio.Final.odt Página 6/40

7 Gestão e Planeamento Como já foi referido, este Estágio foi realizado no seio da USIC do IPN, mas o trabalho em si foi realizado individualmente. Isto não quer dizer que não houve colaboração entre todos os elementos desta equipa, antes pelo contrário. Esta colaboração teve os seguintes participantes, com as respectivas funções: Nuno Pimenta Orientador de Estágio, responsável máximo pela USIC. Gestor de projecto, o qual define os objectivos mais em concreto, politicas de utilização/gestão dos sistemas a implementar. Bruno Teixeira Colaborador mais experiente da USIC, acabou por dar suporte a instalar e configurar hardware, elaboração de um portal em PHP e explicação do funcionamento da rede interna do IPN. Carlos Ramos Colega que mais suporte deu na instalação e configuração dos SO's e funcionamento geral do Linux, explicação do funcionamento da rede interna do IPN. É natural que sem a ajuda destas pessoas não seria possível executar muitas das tarefas, dada a complexidade numa rede de uma instituição como o IPN, para além de ter a USIC como a entidade que mais se aproxima de um cliente real. Ao longo do estágio foram frequentes as reuniões tidas em conjunto, de modo a partilhar ideias, discutir problemas, sugerir propostas, soluções, etc. Antes de se dar início à execução das actividades, foi elaborado um planeamento detalhado para os trabalhos a que foi proposto o Estágio. Este consistiu em primeiro lugar, descrever e sub-dividir cada tarefa proposta pela instituição mais detalhadamente. De seguida planeou-se o tempo de execução para cada uma dessas sub-tarefas, o que possibilitou a construção de um mapa de Gantt completo para todo o projecto. A última tarefa agendada era configurar um sistema de detecção de intrusão, que acabou por ser alterada para um sistema de monitorização de tráfego, após autorização do júri do Estágio. Mostra-se então de seguida esse mapa de Gantt, que possui o escalonamento de todas as tarefas planeadas inicialmente, incluindo o planeamento para o sistema de detecção de intrusão. Relatório.Estágio.Final.odt Página 7/40

8 Mapa de Gantt Planeado Relatório.Estágio.Final.odt Página 8/40

9 Relatório.Estágio.Final.odt Página 9/40

10 O plano apresentado foi cumprido na sua essência, isto é, foram cumpridos os objectivos mas não necessariamente no tempo previsto e por vezes com algumas trocas de ordem das suas tarefas. Para além da actividade do servidor de impressões ter sofrido um atraso maior que o normal, e que consequentemente dava menos tempo para executar a última actividade, chegou-se à conclusão de que um sistema de monitorização de tráfego era mais adequado para ser implementado nesta fase e que este traria mais valor para o IPN. Então, com a aceitação deste novo plano de trabalho para a última actividade, foi elaborado um novo plano para esta. A sua execução correu dentro do esperado, apenas existiu um atraso de cerca de uma semana, o que não causou problema de maior à execução dos trabalhos. Assim, apresenta-se de seguida o plano real executado, que incluí algumas tarefas adicionadas que não estavam previstas e logicamente o plano de execução do monitor de tráfego, entretanto adicionado. Relatório.Estágio.Final.odt Página 10/40

11 Mapa de Gantt Executado Relatório.Estágio.Final.odt Página 11/40

12 Relatório.Estágio.Final.odt Página 12/40

13 Actividade 1 Rede Wireless Descrição Antes de se dar início à implementação da nova rede Wireless no IPN, elaborou-se primeiro um estudo à rede existente anteriormente e os seus resultados encontram-se no anexo 1. Esses resultados deram a conhecer bem as potencialidades do hardware a instalar nos edifícios do IPN, as suas capacidades e limitações. Por fim estudou-se a segurança do acesso com o openvpn que era o método usado. Após esse estudo, pesquisaram-se soluções de software aberto para criação e gestão de credenciais de acesso temporário à rede Wireless e essa pesquisa está documentada no anexo 2. Decidiu-se então, que o sistema a usar seria o captive portal ChilliSpot com o uso do servidor de autenticação freeradius e este com uma base de dados MySQL onde se registam os utilizadores temporários. Quanto aos colaboradores do IPN, decidiu-se então que iriam continuar a usar o openvpn. Para além de se ter verificado que protege toda a comunicação extremo a extremo (desde o cliente Wireless até à rede interna do IPN), esta aplicação já era do conhecimento geral dos utilizadores. O facto de não se optar por configurar o acesso por um outro método seguro, por exemplo WPA, e manter o openvpn, prende-se que para tal seria necessário configurar um suplicante no cliente (diferente em Windows e Linux) para além de outras configurações adicionais no respectivo SO. Isto faria com que se perdesse algum tempo na sua configuração e instalação, pelo que será mais conveniente usar o openvpn. Implementação do sistema Depois de escolhida a solução a implementar e após sucessivos testes de funcionamento com apenas um AP ligado directamente à máquina em que o sistema esteve a trabalhar, chegou-se à fase de preparar todo o sistema a ir para produção. Nesta altura, existiam alguns utilizadores activos no sistema Wireless antigo, pelo que foi necessário elaborar um pequeno plano de migração de um sistema para o outro. Então, para que a migração do sistema anterior para o novo tivesse o menor impacto possível, optou-se por manter os dois AP's em funcionamento na rede antiga e ao lado desses colocar novos AP's, conectados na nova VLAN com o SSID: 'IPN-test'. Procedeu-se então a vários testes com esses novos AP's e quando se verificou que tudo estava em pleno funcionamento procedeu-se à mudança do SSID 'IPN-test' para 'IPN', ficando estes operacionais. De seguida os antigos foram desligados, colocados nos locais planeados e configurados para a nova rede. Localização dos AP's Para identificar cada AP, deu-se a simples nomenclatura de AP-X, em que X representa o número do AP que vai desde 1 até 8. Durante o processo de actualização do firmware verificou-se que um deles tinha a placa de rádio PCMCIA danificada, pelo que esse AP não Relatório.Estágio.Final.odt Página 13/40

14 pode ser instalado. Como o plano de nomeação dos AP's já tinha sido efectuado, o que se encontrava sem funcionar foi o AP-7. Até à data, o AP-7 não se encontra no local pretendido. Ilustra-se de seguida, com as plantas dos edifícios do IPN, a respectiva colocação de cada AP. Figura 1 Colocação do AP-4, dentro da área técnica do auditório. Figura 2 Colocação do AP-3, no bastidor do edifício, dentro da sala de reuniões. Figura 3 Colocação dos AP's 1 e 2, na sala da USIC e de projectos respectivamente. Ambos estão do lado de dentro da sala junto à janela. Figura 4 A vermelho verifica-se a posição planeada para o AP-7, que não foi possível instalar. Colocação do AP-8, à entrada do edifício junto ao tecto. Relatório.Estágio.Final.odt Página 14/40

15 Figura 5 Colocação dos AP's 5 e 6, na antiga sala da UNE e na nova sala de reuniões, respectivamente. Ambos estão do lado de dentro da sala junto à janela. A cobertura de rede do edifício Sul será colmatada após a substituição do AP-7 que deverá ser suficiente para alcançar o restante espaço do piso inferior. Configurações dos AP's Depois de todos os AP's terem sido actualizados com a última versão do firmware existente, foram todos configurados do mesmo modo, mudando apenas o seu IP e o seu nome de estação. O nome da estação é diferente em cada AP porque, para além de o identificar com um nome, o fabricante do equipamento refere que é necessário atribuir nomes diferentes para o correcto funcionamento de roaming, isto é, para que a mobilidade do cliente entre as estações base (AP's) seja transparente para o utilizador. Aplicaram-se as seguintes configurações para todos os AP's: [Wireless Network Name: IPN ] - Nome da rede Wireless, conhecido por SSID. [Station Name: AP-X ] - Nome atribuído a cada AP, em que X é o número dado para a sua identificação. [Country configuration: Portugal] Este parâmetro define os valores das potências de emissão e canais usados pelo o AP, em norma com os regulamentos do país em que se encontra. [Community Name #1: <um-nome-da-comunidade>] - O nome da comunidade é usado para que o protocolo SNMP tenha permissões de leitura de dados estatísticos sobre o AP. Alterouse para um outro nome que não o por defeito. [Anttena type: Indoor] Por defeito estes AP's trazem esta opção como 'Outdoor', uma vez que as placas de rádio possuem um adaptador para uma antena externa. Como não há antenas disponíveis, o seu uso será apenas 'Indoor'. [AP Density: Medium] É recomendado pelo fabricante quando existem AP's próximos uns dos outros, ou quando pelo menos existem vários pontos onde é possível captar sinal de diferentes AP's da mesma rede, o que é o caso. Isto para uma gestão de roaming mais afinada pelos vários AP's, segundo o fabricante. [Disable: CDP, Telnet, Web (TLS)] Estes serviços, suportados pelos AP's, foram propositadamente desactivados pelos seguintes motivos: CDP é um protocolo proprietário do fabricante que serve apenas para a sua gestão através da aplicação que disponibiliza, o AP Manager. O serviço por Telnet é também para gestão do AP por consola, mas como não usa Relatório.Estágio.Final.odt Página 15/40

16 qualquer tipo de encriptação, optou-se por não o activar. O acesso por Web sobre TLS seria seguro, no entanto o serviço não traz mais opções que a gestão por SSH e iria sobrecarregar mais computacionalmente o AP. [Enable: SSH -> RSA 1024bits] Este é o método de acesso de gestão preferido, uma vez que se apresenta como sendo o mais seguro e completo. A chave RSA de 1024 bits foi gerada com uma hash SHA-1, e esta encriptação até hoje em dia relevou-se inquebrável. [Channel: ] Este parâmetro deve ser diferente entre os AP's que interferem uns com os outros (entre os mais próximos) e quanto maior for a sua diferença melhor. Isto para evitar ao máximo interferência entre os próprios AP's. Foram definidos quatro grupos, com os canais 1, 5, 9 e 13 em que os AP's de cada edifício usam cada um desses canais. A norma WiFi escolhida a implementar foi a b, daí a taxa de transmissão entre os AP's e os clientes ser de 11Mbps. Apesar de suportarem a norma g (de 54Mbps), esta não é necessária. Em primeiro lugar, a ligação que o IPN possui para o exterior é bastante inferior a essa velocidade. Depois o acesso à rede na maioria dos casos é apenas para acesso casual à Internet, a partir de estações de trabalho potencialmente móveis. Mesmo para comunicações na rede interna, não se prevê transmissão de grandes quantidades de tráfego entre as estações. Para além disto, a norma b apresenta-se a mais simples e compatível com mais hardware, incluindo o mais antigo. Funcionamento global De forma a demonstrar o funcionamento global de todo o sistema da rede Wireless descrevese uma ilustração do cenário implementado e de seguida da máquina que faz a sua gestão. Os utilizadores representados na rede Wireless poderão ser do tipo convidados ou utilizadores fixos do IPN, isto é, autenticados no ChilliSpot ou conectados via openvpn respectivamente. Figura 6 Cenário implementado para a rede Wireless. Relatório.Estágio.Final.odt Página 16/40

17 Figura 7 Descrição da máquina Router/Firewall da rede Wireless. Utilizadores convidados Assim que o utilizador convidado se liga à rede Wireless, recebe automaticamente as configurações de rede, atribuídas pela aplicação ChilliSpot que contem um servidor de DHCP e trabalha directamente na interface virtual, que por sua vez trata de todo o endereçamento dos clientes Wireless. Posto isto, basta abrir uma página Web qualquer num navegador e então será redireccionado automaticamente para a página de autenticação do ChilliSpot que lhe solicitará as devidas credenciais, como apresentado na figura 8. Neste momento não existe conectividade para a Internet, porque Chillispot bloqueia o utilizador na interface virtual. A página de autenticação é enviada para o cliente pelo Apache através de HTTP/S o que garante a segurança na transferência das credenciais até ao servidor. Figura 8 Portal de autenticação dos convidados. Ao abrir esta página, o utilizador será alertado de que o certificado do servidor não faz parte de uma entidade oficial, porque simplesmente foi gerado localmente, tendo assim os utilizadores de o aceitar e confiar na entidade que o criou. O portal apresentado foi totalmente escrito em PHP e construído para trabalhar com o Chillispot. Disponível gratuitamente na Internet [9], acabou por ser um pouco modificado de modo a apresentar informação adequada aos utilizadores e desactivou-se um pop-up que surgia após autenticação. Foi também criado um ficheiro HTML de ajuda, que pode ser acedido directamente e contém as instruções para acesso à rede Wireless. Relatório.Estágio.Final.odt Página 17/40

18 A comunicação entre o Apache e o Chillispot é segura, porque ambos têm uma password simétrica, no portal PHP (para o Apache) e na configuração do Chillispot. Assim que o ChilliSpot recebe as credenciais do utilizador, contacta o servidor RADIUS para saber se esse utilizador é válido ou não. De um modo análogo ao Apache e Chillispot, na comunicação Chillispot freeradius também se usa uma password simétrica, definida de igual modo nos ficheiros de configuração de cada um. Por fim, o servidor freeradius consulta a base de dados MySQL, de nome 'radius' que contem todos os utilizadores válidos (e também os que já expiraram). Caso o utilizador nunca tenha sido usado ou ainda esteja dentro do tempo a que tem direito, o freeradius responde com um 'access-accept', caso não exista, já tenha expirado ou as credenciais estejam erradas, responde com um 'access-reject'. Após o utilizador ter entrado com sucesso na rede, fica de imediato com ligação à Internet, limitada apenas pelas regras da Firewall do servidor Wireless, que permite tráfego SSH, HTTP, HTTP/S e . No entanto se algum convidado necessitar de mais algum serviço adicional, será necessário abrir esse serviço na Firewall do servidor. A sessão do utilizador convidado irá expirar sempre X horas e Y dias após o primeiro login, independentemente de estar ligado à rede ou não, consoante o tempo que lhe foi atribuído na sua criação. Este comportamento é que torna o utilizador temporário, e a sua verificação é efectuada pelo servidor freeradius. Todos os utilizadores inseridos na base de dados possuem um campo de nome 'Access-Period' que define o tempo máximo de sessão para esse utilizador. Então o próprio freeradius é que compara a data do primeiro login (que fica registada) com a actual e quando essa diferença for superior ao tempo limite, o utilizador é caducado, ficando de imediato sem acesso à rede. Utilizadores do openvpn O Chillispot bloqueia o acesso para a Internet aos utilizadores da rede Wireless, no entanto tem uma opção para dar acesso sem autenticação unicamente a um determinado IP. Então, para se activar a ligação ao openvpn sem autenticação, activou-se no Chillispot o acesso directo apenas à máquina 'openvpn.ipn.pt' e assim é possível ligar directamente à VPN. No entanto devido a alguns problemas com as suas configurações antigas do openvpn, houve a necessidade de se criar novas configurações e novos certificados para todos os utilizadores. Estas novas configurações incluem uma ligação para o IPN a partir do exterior e uma outra ligação para a nova rede Wireless implementada, ficando à escolha do utilizador qual a rede a ligar, dependendo se está fora do IPN ou se pretende ligar à rede Wireless. Figura 9 Ligação do openvpn em Windows, ligado na rede Wireless. A opção em cima, é para ligações a partir do exterior do IPN. Relatório.Estágio.Final.odt Página 18/40

19 Deste modo, a ligação ao openvpn é vista apenas em passagem pelo servidor da rede Wireless, ou seja, o tráfego openvpn é transportado directamente para o 'openvpn.ipn.pt', como ilustrado na figura 7 a laranja. Assim fica-se de um modo transparente dentro da rede do IPN, na VLAN em que o utilizador pertence e naturalmente com acesso à Internet. Página de administração de tickets Wireless Para se proceder à criação e gestão de contas de acesso temporário, foi necessário desenvolver uma pequena página Web. Como a base de dados a aceder é MySQL o modo mais cómodo para esse fim seria escreve-la em HTML e PHP. A referida página encontra-se on-line num sítio público da Internet: wifi.ipn.pt. Esta foi desenvolvida com o propósito de apenas criar credenciais para acesso dos convidados à rede Wireless e também para visualizar o histórico de utilizadores (que são caducados após utilização). É bastante funcional e extremamente simples de usar. As suas funcionalidades são as seguintes: Consultar o histórico de contas de utilizadores, incluindo a data e tempo de acesso por cada um; Verificar as contas disponíveis, que nunca foram activadas ou que ainda estão em utilização; Caducar de imediato uma conta válida, estando o utilizador na rede ou não; Imprimir credenciais de uma conta válida em PDF, podendo guardar o ficheiro no disco ou mandar imprimir em papel; Criar novas contas de duração variável em dias e horas, sendo esse tempo acumulável; Possibilidade de adicionar uma descrição do utilizador, quando é criado; Modificar a descrição de um utilizador, activo ou não; Alterar a password do administrador do portal. Esta área de gestão de contas temporárias foi necessária devido à complexidade dos passos que eram necessários para se criar um utilizador manualmente na base de dados. Assim criou-se um sistema de criação de tickets temporários, implementando apenas as funcionalidades que foram tidas em conta após uma análise e discussão daquilo que serviria completamente as necessidades requeridas pelo IPN. Figura 12 Portal de administração de contas Wireless. Desde a sua última versão funcional, que data da entrega do relatório preliminar, foram adicionadas algumas funcionalidades neste portal, que vieram ao encontro de melhorar o seu Relatório.Estágio.Final.odt Página 19/40

20 funcionamento segundo as necessidades requeridas pela equipa USIC. Então essas modificações foram as seguintes: Adicionado o logótipo do IPN no topo das páginas; A visualização das contas caducadas e válidas em tabelas, foram repartidas por um número máximo por página, possibilitando a navegação simples entre páginas; No histórico passou a ser possível modificar a descrição de cada utilizador; No histórico de cada utilizador é possível verificar alguma informação relativa às sessões que realizou, assim como o endereço MAC do cliente, o IP atribuído na rede Wireless, o tempo total de cada sessão, a data e hora de início e fim de cada sessão; Cada ticket passou a ter um identificador unívoco, que surge no destinatário dos envelopes criados em PDF, ficando a sua descrição oculta em baixo; Ao criar um ticket, é possível colocar a sua duração em horas e dias. A sua visualização, tanto na página como nos PDF's é sempre no formato: X horas e Y dias; As passwords dos convidados passaram de 6 dígitos numéricos para 8 dígitos alfanuméricos; Segurança O portal desenvolvido, está alojado na rede externa do IPN no endereço Web wifi.ipn.pt, e foi alvo de uma auditoria de segurança pela equipa do CERT-IPN (Computer Security Incident Response Team - IPN), assim como todos os serviços disponibilizados nessa rede interna e externa. Esta auditoria procurou verificar as suas vulnerabilidades, acesso de entrada nele e foi exaustivamente testado contra injecção de código SQL nas credenciais a inserir. Isto porque a verificação do utilizador que tem acesso ao referido portal é feita na base de dados MySQL e o parse da String inserida que vai para o PHP pode ser tentada a conter código malicioso por um atacante. As Strings a introduzir são analisadas com uma função que protege e diferencia o uso de caracteres mágicos (como, ', \ ou NULL), ficando assim seguro de ataques por injecção de código SQL. Nesta fase, o site deu-se como seguro, pelo menos no seu acesso principal. Após a fase de testes de penetração no portal, foi cedido à equipa que realizou a auditoria, uma password temporária do administrador para se efectuarem testes internos ao portal, isto é, depois de autenticados testaram exaustivamente a sua segurança. Estes testes tiveram como resultado um Stress da base de dados, pois foi possível inserir muita informação mal formatada no MySQL e acabaram por dar ao portal algumas inconsistências na informação que este mostrava ao administrador. Isto não colocou em causa a informação que estava lá anteriormente, apenas se concluiu que nem sempre há uma verificação dos dados a inserir. Depois disto, restaurou-se a base de dados, a qual se tinha efectuado backup anteriormente. De modo a resolver este problema basta, efectuar uma verificação de toda a informação a inserir na base de dados e só permitir essa inserção caso a informação seja válida. Quanto à segurança da rede Wireless em si, pode-se afirmar que é totalmente segura pelo acesso através do openvpn (como referido no anexo 1) e também o acesso aos convidados é feito em segurança como foi explicado neste documento. Existe no entanto uma pequena vulnerabilidade, que se acredita não colocar algum problema, que é a seguinte: assim que alguém se liga à rede, antes de obter ligação (com openvpn ou ticket temporário) é possível resolver pedidos de DNS para a Internet. Isto foi activado propositadamente para os clientes do Relatório.Estágio.Final.odt Página 20/40

21 openvpn obterem resolução do nome 'openvpn.ipn.pt' e que posteriormente permite a ligação a esse servidor. Para desactivar a resolução de DNS, os clientes do openvpn terão de ter configurado o acesso directo ao IP da máquina em questão, pelo que de momento isso implica modificações nas configurações dos clientes actuais. Posto isto, era possível desactivar o acesso à resolução de pedidos DNS antes de qualquer autenticação, tanto por openvpn como pelo acesso dos convidados. Conclusões e resultados O sistema implementado teve um pequeno atraso relativamente ao previsto devido ao facto de não se ter planeado inicialmente a construção da página de administração, pois pensava-se que existiam ferramentas open-source que solucionassem o problema da criação de tickets ou contas temporárias. Mesmo assim os objectivos principais desta actividade foram realizados com sucesso e de momento o sistema encontra-se em produção há bastante tempo. A sua utilização por parte dos colaboradores do IPN tem sido frequente e bem aceite até hoje em dia. Quanto aos convidados, o sistema tem sido usado ocasionalmente como previsto, e encontrase bastante funcional e sem problemas encontrados até à data. Em relação ao funcionamento dos dois modos de acesso em diferentes SO's, sabe-se que não existem incompatibilidades em sistemas recentes, pois durante a implementação e testes efectuados foi usado Windows XP e Linux Gentoo, no entanto existem colaboradores com Windows Vista e Mac OS X que para o openvpn, apenas necessitam de instalar uma versão especifica compatível com o respectivo SO. Quanto aos utilizadores temporários estão completamente livres do SO a usar, não sendo preciso instalar nada, para além de um navegador Web (por ex. Firefox, Internet Explorer, etc.). Também foi possível verificar o acesso com uma conta temporária, com um PDA que suporta WiFi e que possui um navegador Web. Quanto à cobertura da rede nos dois edifícios do IPN, foi testada ao longo da colocação dos AP's e corresponde à necessidade de ocupar toda a área prevista. O edifício Norte está com cobertura total, pois colocaram-se os 4 AP's pretendidos, enquanto o edifício central ficou só com 3, pelo que poderá ter alguma falha de sinal, principalmente no piso 0, do lado oposto da entrada principal. Mesmo em alguns locais onde o sinal é sempre um pouco mais fraco, verificou-se a possibilidade de se obter ligação à rede. Foram também efectuados alguns testes ao Roaming entre AP's, ou seja, a garantia da mobilidade dos clientes entre as diferentes estações base, como ilustrado na figura 13. Uma vez que os AP's instalados fazem todos parte da mesma rede, com o SSID 'IPN', inseridos todos na Figura 13 Roaming, entre duas estações base (AP's). Relatório.Estágio.Final.odt mesma VLAN, e com um identificar Página 21/40

22 único em cada um (o nome da estação), deveria existir a funcionalidade de Roaming (suportada pelos AP's), também conhecida por hard-handoff, que passa por o utilizador alterar a sua posição e estação WiFi a que está ligado, sem que perca conectividade à rede de uma forma automática e transparente para o cliente. Esta funcionalidade é possível porque existe uma 'cooperação' de comunicação entre a interface Wireless do cliente e os próprios AP's e que têm obrigatoriamente de estarem a utilizar a norma WiFi b, como foi a implementada nesta rede. Alguns testes efectuados a esta funcionalidade confirmaram aquilo que se esperava, ou seja tiveram sucesso. No entanto quando se perde o sinal do AP onde estava anteriormente verificaram-se alguns segundos sem ligação que acabou por ser restabelecida logo depois de uma forma automática. Para efectuar os testes, colou-se um computador portátil ligado à rede Wireless e a fazer ping's consecutivos ao servidor (que são feitos de um em um segundo), enquanto se deslocou o portátil de um sítio para outro, onde a cobertura de rede era assegurada por outro AP. Resta observar que depois de algum tempo em produção e em fase estável, fez-se um backup total do servidor implementado. Não só para salvaguardar os dados, mas também de modo a obter uma rápida reconfiguração de todo o sistema ou até só de algum serviço ou aplicação, caso algum imprevisto grave aconteça. Durante o tempo em produção, foram executadas as actualizações de sistema com uma certa regularidade, tipicamente aos fins-de-semana. Para realizar backups e actualizações, procedeu-se como descrito no anexo 9. A restante manutenção ou procedimentos que sejam necessários efectuar na rede Wireless são descritos no manual elaborado para tal e que se encontra no anexo 3. Relatório.Estágio.Final.odt Página 22/40

23 Actividade 2 Servidor de Impressões Descrição No inicio desta actividade existiam três impressoras na sala de apoio do IPNlis e uma outra, à entrada do edifico Norte. As instaladas na sala de apoio, estão partilhadas directamente na rede e apenas uma delas necessita de um print-server físico por não possuir interface de rede (apenas porta paralela). Quanto à impressora que ainda não se encontra ligada à rede, apenas funciona como fotocopiadora, estando previsto no futuro a sua utilização partilhada por todos os utilizadores do IPN, com o sistema de contabilização em funcionamento. Deste modo, os colaboradores do IPN apenas tem de configurar na sua estação de trabalho, a impressora remota em que pretendem imprimir, tendo que inserir o endereço IP da respectiva impressora e finalmente instalar o devido controlador (driver). Naturalmente não existe nenhum sistema que permita contabilizar o número de impressões que cada utilizador efectua, o que leva a crer, que ocasionalmente haja alguns colaboradores tenham a necessidade de imprimir quantidades superiores aos restantes. Isto faz com que possam existir despesas de consumíveis (tinteiros, tonners e papel das impressoras) algo desproporcionais entre os vários laboratórios do IPN ou grupos de projectos do mesmo laboratório. O objectivo deste trabalho passou então por contabilizar todas as impressões por cada utilizador, de modo a poder repartir justamente os custos de impressão pelos diferentes laboratórios ou por certos projectos que possam ter um financiamento independente. Implementação do sistema Após o estudo e testes efectuados sobre soluções a implementar, presente no anexo 4, decidiu-se que o sistema a utilizar seria o CUPS como gestor de impressoras partilhadas e o PyKota como o contador de impressões por utilizador. Foi necessário aproveitar uma máquina existente para se instalar o sistema e foi nessa que se realizaram alguns testes de funcionalidades ás soluções encontradas. Como habitual, instalou-se o SO Gentoo Linux. Entretanto, durante a implementação do novo sistema, o antigo manteve-se inalterado de modo a que os colaboradores do IPN continuassem a imprimir sem problemas. Simplesmente configurou-se o servidor com uma interface de rede na área dos servidores do IPN. O seu acesso só é possível a partir da rede interna, pelo que foi adicionado nos servidores de DNS internos do IPN. Como pode ser analisado na figura 14, o servidor de impressoras ficou na VLAN dos servidores, enquanto que as impressoras estão na VLAN do IPNlis. Todo o tráfego inter VLAN's passa sempre na máquina Firewall, pelo que no futuro irá ser criada uma VLAN para as impressoras Relatório.Estágio.Final.odt Figura 14 Localização das impressoras e do novo servidor. Página 23/40

24 onde apenas o servidor de impressoras terá permissões de acesso, tendo os utilizadores que aceder ás impressoras através desse servidor para poderem imprimir. Logicamente a contabilização é efectuada nesse servidor, onde está configurado o CUPS com as impressoras existentes instaladas e com o PyKota em background para proceder à contabilização de impressões. A máquina onde se instalou o sistema passou a ser acedida apenas na rede interna do IPN pelo nome de 'print' ou 'print.ipn.pt', bastando para isso adicionar essa informação nos servidores de DNS internos. Assim, para se poder imprimir o utilizador terá obrigatoriamente de estar conectado na rede interna, que também é possível com o openvpn a partir da rede Wireless ou do exterior. CUPS A instalação e partilha das impressoras neste sistema foi relativamente simples, uma vez que após o estudo e testes do anexo 4, concluiu-se que o melhor método para partilhar as impressoras era usar IPP sobre HTTP/S. No entanto, uma das impressoras mais antigas, a HP1125C está ligada a um print-server físico (Axis 540+) que não suporta IPP e teve de ser instalada com Sockets (JetDirect no porto 9100 TCP). Apesar da ligação do servidor para essa impressora ser por Sockets, a comunicação do cliente para o servidor é por IPP. Quando o documento a imprimir chega ao servidor é que é transferido pelo CUPS para a impressora através de Sockets. As outras duas, a HP4350 e a Oki5400n, possuem interface de rede própria e suportam o protocolo IPP, pelo que estão configuradas directamente com este protocolo no CUPS. Posto isto, foi apenas necessário verificar quais os controladores PPD (ficheiros de drivers) que estavam em conformidade com a respectiva impressora. Procurou-se nos sites dos fabricantes oficiais as versões mais recentes dos controladores para Linux. Para instalar uma impressora do servidor 'print' num cliente (tanto em Windows como em Linux), basta adiciona-la como uma impressora remota e no seu endereço colocar o respectivo URI que é identificado pelo IP do servidor e nome da impressora que partilha. Como as impressoras foram todas instaladas no servidor por IPP, o seu URI dado por defeito é: em que 631 é porto onde o protocolo IPP trabalha e consequentemente onde o CUPS aceita ligações. De seguida é necessário indicar o controlador correcto, para o SO em uso. Foi elaborada uma página Web, alojada na área de suporte técnico do IPN em suporte.ipn.pt (Instalação de Impressoras), de suporte aos utilizadores para instalarem as impressoras. No anexo 6 encontram-se os screenshot's dessa página. Relatório.Estágio.Final.odt Página 24/40

25 Autenticação dos utilizadores Para a contagem de impressões por utilizador ser real, era bastante conveniente que estes se autenticassem no servidor 'print' do mesmo modo que nos restantes serviços oferecidos pelo IPNlis (Sistema de Informação, , etc.). Para tal, existe um servidor de autenticação de nome 'kerberos.ipn.pt'. Basicamente é uma máquina de SO Windows que incorpora o serviço de Active Directory para domínios Microsoft, mas também implementa os protocolos LDAP e Kerberos. O CUPS foi testado inicialmente sem forçar a verificação de um utilizador válido, o que fazia com que o nome do utilizador de todos os trabalhos de impressão enviados para o servidor fosse o da sessão do próprio SO em uso. Uma vez que os colaboradores do IPN não necessitam de efectuar login nas maquinas de trabalho (através de domínios Windows, por ex.), até porque usam uma variedade de máquinas, SO's, etc., este método de identificar os utilizadores era muito ineficaz, daí a necessidade de configurar o CUPS a forçar a autenticação dos utilizadores do 'kerberos.ipn.pt'. Assim, para cada impressora instalada no CUPS, adicionou-se a opção de forçar o uso de um utilizador, que será visto como local, ficando o SO encarregue de verificar se esse utilizador é válido ou não no servidor de autenticação. Para efectuar essa verificação, usou-se o Samba com o Winbind [20], instalados e configurados no servidor 'print', de modo a receber a aceitação dos utilizadores no 'kerberos.ipn.pt'. Foi necessário instalar o Samba e o Krb5 (Kerberos v5) com suporte de PAM (sistema de autenticação do Linux) para verificar localmente, de um modo transparente, se as credenciais cedidas nesse sistema são válidas no servidor de autenticação principal. PyKota Esta foi a solução mais adequada que se encontrou para servir os objectivos desta tarefa. O PyKota funciona como um backend do CUPS, isto é, quando algum trabalho é enviado para a fila de impressão do CUPS, o PyKota é executado para tratar o pedido e por sua vez este corre um método de acesso à respectiva impressora (através de IPP, Sockets, porta paralela, USB, etc.) que o CUPS suporta. Assim, ao instalar as impressoras no servidor é obrigatório adicionar sempre este backend, de nome 'cupspykota', de modo a verificar a contagem de impressões. Para registar permanentemente o histórico de impressões dos utilizadores, este programa configurou-se com o MySQL. Uma vez que a autenticação dos utilizadores é da responsabilidade do CUPS, a sua base de dados apenas tem os nomes de utilizadores que já usaram o sistema e são precisamente os que chegam ao CUPS. Para isso, tem um plano de inserção automática do utilizador, quando este ainda não existe na base de dados, ou seja, quando um certo utilizador imprime neste sistema pela primeira vez. Depois de criado, cada utilizador tem um número de impressões realizadas em cada impressora bem como o histórico em cada uma. Esse número de impressões pode ser reiniciado para todos os utilizadores, usando um comando específico do PyKota. Esta aplicação possui uma variedade de comandos que facilitam a inserção e consulta de dados no MySQL, assim como a adição de utilizadores e Relatório.Estágio.Final.odt Página 25/40

26 de impressoras, de definição de quotas, custos por impressão em cada impressora, a visualização de quotas/impressões realizadas pelos utilizadores. Apesar de ter sido pensado para estabelecer quotas por utilizar, essa funcionalidade foi desactivada, pois não se pretende de modo algum impor limites ao número de impressões que cada utilizador efectua. A principal funcionalidade deste programa é então contabilizar o número de impressões (de páginas) impressas por cada trabalho de impressão (ou documento impresso) e para tal possui dois modos distintos para efectuar essa contagem: Por software: a aplicação utiliza um parser aos documentos enviados para imprimir, que ao analisar o seu conteúdo, diz quantas páginas deve ter. Este método não é muito eficaz, pois pode não reconhecer o formato do documento a imprimir. Existe uma aplicação que pode ser usada para esta contagem, do mesmo autor do PyKota, chamada 'pkpgcounter', que foi desenvolvida para realizar o melhor possível nesta situação, por suportar muitos formatos de documentos usados hoje em dia, mas mesmo assim insuficiente para analisar os muitos formatos proprietários e fechados que eventualmente os utilizadores usem. Por hardware: neste caso o PyKota vai tentar ir directamente à impressora para ler o número de páginas que já foram impressas. Antes de enviar o trabalho para a impressora, verifica se esta está livre e em caso afirmativo lê o seu contador interno do total de páginas impressas. Imediatamente envia o trabalho a imprimir, e frequentemente 'pergunta' à impressora se ainda está ocupada. Assim que verificar que já está livre de novo, lê outra vez o contador interno global e faz a diferença com o inicial, obtendo assim o número real de páginas impressas por esse trabalho. A comunicação usada com as impressoras pode ser através de SNMP ou PJL (Sockets). Este modo de contabilização é ilustrado na figura 15. Figura 15 - Cenário do CUPS com o PyKota a contabilizar por hardware. Relatório.Estágio.Final.odt Página 26/40

27 Problemas encontrados Com o objectivo de implementar uma solução que contabilize correctamente todos os documentos impressos em todas as impressoras, o método de contagem a utilizar foi o por hardware, por se apresentar o mais fiável. O primeiro problema que surgiu, foi o facto da impressora HP1125C estar ligada por um print-server físico que, apesar de comunicar por SNMP, não possui contador global de páginas interno. Isto faz com que o PyKota obtenha sempre uma página impressa independentemente do tamanho do documento. Após verificação à variável SNMP, concluiu-se que esse valor é apenas o número de trabalhos impressos nessa impressora. Como a impressora em questão é algo lenta e antiga (só tem a vantagem de imprimir em A3), acaba por ser pouco usada. Então decidiu-se que apenas iria contabilizar o número de documentos impressos por cada utilizador, que faz correctamente nesse sentido, e sempre é preferível do que a contabilizar por software. O maior problema desta actividade, esteve relacionado com a verificação do método de contagem para a impressora Oki5400n. Depois de ter a HP4350 a contabilizar correctamente por hardware com SNMP, a Oki5400n continuava em não contar o número certo para documentos grandes. Com o suporte das ferramentas snmpget e snmpwalk, confirmou-se positivamente que a variável SNMP a ler na impressora era a correcta e que representava o histórico global de impressões totais na impressora. Procedeu-se então à verificação do estado da memória da impressora antes e depois de se imprimir, o que também não explicou o problema, pois o contador global apresentava os números correctos. O que se passou foi que, como possui muita memória para cache de trabalhos em fila de espera (128 MB), a impressora consegue processar rapidamente o documento a imprimir e 'diz' ao PyKota através de SNMP, que já está livre pouco tempo depois de ter começado a imprimir um documento grande. Nesta situação, o PyKota verifica o contador global cedo de mais (enquanto a impressora ainda imprime), dando sempre um número de impressões sempre inferior ao real (para documentos com mais de 5-6 páginas). Para verificar estar situação, teve-se de se monitorizar os logs do PyKota em tempo real de impressão e em simultâneo contar as páginas reais impressas. O que a impressora faz correctamente é a actualização em tempo real do contador enquanto imprime. A solução para este problema, foi mais simples do que se esperava e passou por usar PJL em vez de SNMP, que basicamente lê directamente os dados em modo binário na impressora. Depois disto, verificou-se a leitura correcta e no momento certo, do contador global, para além de ser ter efectuado bastantes testes a confirmar os resultados esperados, que se encontram no anexo 6. Também ao imprimir páginas em branco no modo duplex nos testes, verificou-se que a HP4350 contabiliza a impressão de duas páginas nos dois lados da mesma folha como 2 cópias, enquanto a Oki5400n contabiliza apenas 1 cópia imprimindo do mesmo modo. Esta situação deve-se mais uma vez, ao modo diferente como cada fabricante implementou a contabilização, mas como é lógico, não é comum os utilizadores imprimirem páginas em branco, daí não se considerar um problema. Relatório.Estágio.Final.odt Página 27/40

28 Automatização das estatísticas de impressão A informação que o PyKota regista fica guardada na base de dados MySQL e aí é possível verificar as estatísticas de impressões de cada utilizador em cada impressora. Como esta forma de acesso à informação não é muito prática para consultas intensivas, o PyKota inclui na sua distribuição um script CGI para a consulta desses dados, que foi instalado no servidor Web da máquina (Apache). Para além de automatizar o acesso à informação na base de dados, apresenta numa página Web o número de impressões de todos os utilizadores em cada impressora instalada, assim como o histórico de cada utilizador na respectiva impressora. Esta página foi devidamente protegida com o uso do htacess do Apache, em que as credenciais são do conhecimento da USIC, para além do seu acesso ser apenas interno ao IPN. Existem portanto dois contadores para cada utilizador em cada impressora, um representa o actual e o outro o histórico. O actual pode facilmente ser reiniciado com um comando, que pode ser programado para ser executado periodicamente com recurso do Vixie-Cron por exemplo. De modo à equipa USIC verificar periodicamente o número de impressões totais e também para cada utilizador verificar a sua utilização nas impressoras foram criados dois scripts em PHP para envio de , em que um serve para enviar toda a informação para a USIC e o outro para enviar individualmente a cada utilizador que usou as impressoras. Depois de estes dois scripts serem executados, procede-se de imediato à reinicialização dos contadores, com o comando específico para tal do PyKota. Para executar este procedimento periodicamente usou-se o Vixie-Cron e de momento este é executado semanalmente, à uma hora da madrugada de cada Sábado. Este período pode ser facilmente modificado à medida das necessidades, para isso deve-se consultar o manual de procedimentos do servidor de impressões, presente no documento de anexo 5. Basicamente o primeiro script envia um para a equipa USIC, que contém todas as impressões realizadas nessa semana por todos os utilizadores, incluindo o seu histórico, enquanto que o segundo script envia um individual a cada utilizador que nessa semana usou o servidor de impressoras e apresenta apenas o total impresso por ele em cada uma, incluindo também o seu histórico. Para o suporte de envio de s no PHP, foi usada a ferramenta open-source PHPMailer v2.0 [22]. Conclusões e resultados Actualmente o sistema encontra-se estável e funcional, e é usado por alguns colaboradores do IPN, mas devido ao facto de não ter sido possível testa-lo com o Windows Vista no cliente, ainda não se colocou em produção, isto porque já existem alguns utilizadores com este SO. Apesar desse facto, a implementação revelou-se eficiente na contabilização do número de impressões que cada utilizador realiza. À semelhança do servidor da rede Wireless, os backups e actualizações deste servidor de impressoras foram realizados ao longo dos últimos tempos, como descrito no anexo 9. Relatório.Estágio.Final.odt Página 28/40

29 Em relação ao seu desempenho por vezes encontra-se um atraso desde que se envia o documento para imprimir até começar a ser impresso, isto porque em primeiro lugar o documento viaja na rede duas vezes, do cliente para o servidor e deste para a impressora, enquanto no sistema antigo era directo dos clientes para as impressoras. Em segundo lugar verificou-se que alguns documentos a imprimir são descomprimidos pelo cliente e ficam mais pesados (por ex. um PDF que ocupe poucos KB, pode ser enviado com alguns MB). Verificouse que este facto depende do documento em si e também dos controladores usados tanto pelo cliente como pelo servidor. Quando estes não conseguem interpretar o conteúdo do documento, simplesmente convertem-no para binário (raw) o que leva ao aumento do tamanho dos dados a transferir para a impressora. Também ainda há uma opção no PyKota que faz com que este verifique se a impressora está livre antes de imprimir e para isso espera 30 segundos, ou melhor, faz essa verificação 6 vezes de 5 em 5 segundos e caso esteja sempre 'idle' é que se considera mesmo livre. Isto porque, como o sistema antigo ainda se encontra a funcionar, pode haver alguém a imprimir na impressora antes do servidor. Caso este sistema fosse o único modo de impressão disponível, não era necessário verificar se a impressora está livre antes de enviar o documento porque o próprio servidor é que mantém a fila de trabalhos a imprimir nessa impressora, logo a verificação era no próprio gestor de impressões (no CUPS). As impressoras de diferentes fabricantes revelaram-se por vezes intrigantes pelo seu comportamento. Apesar de existir um esforço internacional de normalização de protocolos e normas entre fabricantes de impressoras, a execução de funcionalidades semelhantes nem sempre têm o mesmo resultado, daí as dificuldades de implementação desta actividade. A sua manutenção que é realizada pela USIC, é muito importante, pois durante os trabalhos executados verificou-se que os maiores problemas são quando a impressora envia uma mensagem de erro genérica para o servidor, que pode significar falta de papel, de tonner, fuser ou tinteiro, pode ter encravado o papel à saída, etc.. E assim deste modo, o trabalho fica em fila de espera no servidor e o utilizador não consegue imprimir. Para resolver este problema (entre outros) da melhor maneira possível, deve-se consultar o manual elaborado para a manutenção do servidor de impressoras que se encontra no anexo 5. Relatório.Estágio.Final.odt Página 29/40

30 Actividade 3 Monitor de Tráfego Descrição O acesso ao exterior da rede do IPN, nomeadamente à Internet, é efectuado através de um circuito dedicado que oferece boa qualidade de serviço para o débito que oferece e que é igual à entrada e à saída. No entanto, a variedade e quantidade de utilizadores que acedem ao exterior faz com que por vezes haja uma pesada utilização dessa ligação e que por vezes encontra-se lenta. Outro facto é que existem alguns colaboradores e/ou laboratórios que usam mais a ligação do que outros. Como o seu custo é elevado e é pago pelo IPN, faz com não esteja racionalizado pelos diferentes laboratórios ou projectos em específico. Esta actividade visa em primeiro lugar, contabilizar a quantidade de tráfego à entrada e à saída para o exterior, que cada laboratório realiza. Em segundo lugar, pretende-se que sirva de ferramenta de estudo para a implementação de um classificador e gestor de prioridades de tráfego para o referido circuito, caso haja necessidade para isso no futuro. Implementação do sistema Para implementar o sistema de contabilização de tráfego, decidiu-se colocar a ligação principal de acesso da Firewall em modo Port Mirror para uma máquina em concreto que irá efectuar a leitura e contabilização pretendida. A principal razão para tal cenário, é o facto da sua simplicidade e de não criar mais um ponto crítico da rede, para além da já existente que é a própria máquina Firewall. Isto foi possível depois de se ter verificado que o Switch existente no IPN permite esta funcionalidade. Descreve-se de seguida então esse cenário: Figura 16 Port Mirror, no Switch principal do IPN. O tráfego entre as diferentes VLAN's (a azul) e destas para o exterior, é necessariamente filtrado pela máquina Firewall, daí ser um ponto critico, porque por exemplo se essa máquina falhar, toda a rede interna do IPN fica sem ligação ao exterior e até entre as próprias VLAN's. Relatório.Estágio.Final.odt Página 30/40

31 Com a funcionalidade de Port Mirror, todo o tráfego que passa nessa ligação (a verde) pode ser 'espelhado' para uma outra porta, ficando a máquina de monitorização independente da rede (porque apenas recebe tráfego) e não causa um ponto crítico, isto é, se essa máquina falhar, a rede mantém-se inalterada. Olhando para a figura, coloca-se a questão de porque não efectuar Mirror na porta em que o Router liga (a vermelho), porque todo o tráfego que entra e sai do IPN também por aí passa obrigatoriamente. A resposta é simples: porque desse modo não é possível analisar o tráfego individual de cada utilizador, mas apenas o total de cada VLAN e de cada servidor, que possuem endereço externo (público). A desvantagem da solução escolhida é o facto de também capturar todo o tráfego interno, mas este pode ser facilmente descartado com regras para filtrar apenas o tráfego de e para o exterior. Uma vez que o tráfego recebido pela máquina de monitorização é 'espelhado' de outra porta física a nível do Switch, o tráfego recebido aí não é direccionado em layer 2 (endereço MAC de destino) para a interface de escuta. Assim é necessário colocar a ferramenta de monitorização em modo promíscuo, de modo a que não 'confie' nos MAC's que vê, isto é, captura toda a informação que chega à placa de rede. Visto que o cenário escolhido para implementar o monitor de tráfego obriga a que a aplicação a colocar em monitorização capture o tráfego em modo promíscuo, ou seja as soluções estudadas (no anexo 7) IPAC-NG e Layer-7 Filter estão fora de questão, uma vez que estas dependem do iptables e este não captura pacotes nesse modo. As soluções escolhidas foram então o NTop e o PMACCT, que podem trabalhar em simultâneo na mesma máquina e serão configurados de modo a obter um tipo de informação diferente, mas que no entanto analisa o mesmo acesso. Então assim temos o NTop que fornece eficientemente o estado actual da rede, assim como a quantidade de dados por tipo de tráfego usado (layer 3). Sempre que haja problemas de acesso (lentidão, atraso, etc.), o NTop deverá ser consultado e é bastante provável que se identifique o problema rapidamente. Concluiu-se que não era viável o registo permanente dos dados que esta ferramenta adquire, pois são em grande quantidade (na ordem de alguns Giga Bytes diários) e o seu crescimento é contínuo com a utilização da rede, para além da consulta dessa informação, em formato RRD, ser complexa. Deste modo, a informação apresentada pelo NTop, é referente no mínimo das últimas 12 horas e de no máximo das últimas 24 horas, dependendo esta variação da quantidade de recursos que a aplicação consome na máquina onde corre. A gestão dessa informação e a consequente limpeza do histórico é realizada automaticamente pelo NTop. Quanto ao PMACCT, é uma ferramenta que obviamente também trabalha continuamente e é a aplicação que regista todo o tráfego em bruto de todas as VLAN's do IPN, de e para o exterior. Os dados que obtém são guardados numa base de dados MySQL e a sua consulta é bastante simples com o front-end BWstat, que apresenta os dados referentes a uma data à escolha num portal Web. Relatório.Estágio.Final.odt Página 31/40

32 De modo a não capturar tráfego interno na ligação da Firewall, estas duas aplicações tiveram de ser configuradas com um filtro comum, que é usado pelo libpcap (dependência necessária das aplicações para capturar tráfego em modo promíscuo). Este filtro é composto por dois grupos lógicos, em que o primeiro define que não se quer capturar tráfego entre as redes locais e o segundo anula o tráfego directo para as interfaces externas definas na Firewall e que aí fazem NAT. Para uma análise mais detalhada desta situação, consultar o anexo 8. Deste modo o filtro 'corta' todo o tráfego que é local e apenas se contabiliza o que tem como destino ou origem a rede exterior, ou seja, a Internet. NTop Devido à maior desvantagem desta solução, que é o uso intenso de recursos, este foi configurado de modo a ser o mais optimizado possível em termos de desempenho. No entanto, sendo a máquina de capacidades aceitáveis (Pentium4 a 2.4Ghz, 512Mb RAM), nunca se notaram problemas deste género, uma vez que o NTop efectua uma gestão automatizada dos recursos de que dispõe. Após várias análises ao estado do sistema, com o 'top', verificou-se o NTop nunca utilizou de mais 16% do total da memória, enquanto a nível de processador é variável e mantém-se bastante baixo (menos de 4%). As opções que se configuraram no NTop foram as seguintes: - local-subnets: indicam-se as gamas de IP's locais, para se destingir os hosts locais e remotos. - disable-decoders: os decoders do NTop verificam informação em layer 2 sobre protocolos que usam esta camada; como consome muitos recursos e não há necessidade de obter este tipo de informação, desactivou-se. - no-mac: captura todos os pacotes, mesmo que o endereço MAC de destino não seja a interface de rede a escutar, ou seja, activa-se o modo promíscuo. - disable-sessions: desactiva a monitorização de ligações TCP, pois não é necessária. - user: define o utilizador a correr o NTop. Criou-se um utilizador normal 'ntop' para esse fim. - domain: define o domínio local, que é 'ipn.pt'. - disable-schedyield: o NTop usa este tipo de funções no seu código, que eventualmente causam deadlocks e o servidor Web deixa de responder, daí se ter desactivo. - protocols: especifica os protocolos de layer 3 a serem contabilizados e apresentados em classes separadas na interface Web. Usou-se uma lista registada num ficheiro em separado, e esse ficheiro é indicado nesta opção. - db-file-path: indica a directoria onde mantém ficheiros permanentes, assim como cache de DNS, password de acesso, etc. Relatório.Estágio.Final.odt Página 32/40

33 - interface: indica o nome da interface de rede onde monitoriza, neste caso é na que recebe tráfego em Port Mirror. - filter-expression: filtro de captura do libpcap, equivalente ao tcpdump. Definidas as opções de funcionamento e com o NTop a correr, na interface Web activou-se a opção de proteger o portal através de password para o utilizador 'admin', que é do conhecimento da USIC. Esta opção fica disco, caso reiniciado, permanente o em NTop continua a seja forçar autenticação. Este método de protecção é semelhante ao htacess do Apache e trabalha no Figura 17 - Menu principal do NTop. servidor Web que o NTop incorpora. Quando se acede ao portal, surge de imediato o pedido das credenciais ao utilizador. Esta protecção foi necessária devido à sensibilidade da informação que a aplicação podia revelar na rede interna do IPN. PMACCT A configuração desta ferramenta é bastante simples, bastando para isso definir a interface onde se pretende contabilizar o tráfego, activar o modo promíscuo, indicar as gamas de rede a agregar tráfego (por VLAN, à entrada e à saída), definir o filtro libpcap (igual ao do NTop) e finalmente indicar os dados para acesso ao MySQL (credenciais, local, nome da base de dados, etc.). Foi possível configurar a base de dados do MySQL em Round Robin, isto é, definir um tempo de actualização dos dados obtidos e um tempo limite para deixar esses dados permanentes, que são de 5 minutos e 1 hora respectivamente. Ou seja, o PMACCT actualiza os dados de 5 em 5 minutos nos mesmos registos (vai somando a quantidade de tráfego) e ao fim de 1 hora, esses dados ficam fixos na base de dados e continua a guardar dados noutros registos. Crescimento da base de dados Visto que esta aplicação guarda os dados de uma forma constante e permanente na base de dados do MySQL o seu crescimento é linear com o passar do tempo. Foi elaborado um pequeno estudo do seu crescimento uma vez que se pretende manter o serviço em monitorização permanente. Em primeiro lugar contabilizou-se o tamanho de cada registo que o PMACCT efectua e que representa para uma rede interna definida (uma VLAN) os seus dados totais à entrada ou à saída. A tabela que regista esses dados chama-se 'acct' e possui os seguintes campos, com o respectivo tamanho: Relatório.Estágio.Final.odt Página 33/40

34 Campo Tipo Tamanho mac_src char(17) 17 bytes mac_dst char(17) 17 bytes ip_src char(15) 15 bytes ip_dst char(15) 15 bytes src_port smallint(5) unsigned 2 bytes dst_port smallint(5) unsigned 2 bytes ip_proto char(6) 6 bytes packets int(10) unsigned 4 bytes bytes bigint(20) unsigned 8 bytes stamp_inserted datetime 8 bytes stamp_updated datetime 8 bytes Total: 102 bytes Tabela 1 Descrição e tamanho dos registos da tabela 'acct' da base de dados do PMACCT. Estes valores do tamanho de cada campo foram verificados na base de dados e confirmados no manual do MySQL [10]. Assim tem-se para cada registo inserido 102 bytes de informação, que é registado duas vezes por cada VLAN definida no ficheiro de redes locais do PMACCT. Como as redes existentes são 14 no total e são guardados dois registos por cada, temos 28 registos de 102 bytes cada, por cada hora, ou seja 102x28 = 2856 bytes por hora, que convertendo para outras unidades para cada tempo: 1 Hora 1 Dia 7 Dias 30 Dias 2.79 Kb Kb Kb 1.96 Mb 1 Ano 5 Anos 10 Anos Mb Mb Mb Tabela 2 Previsão do crescimento máximo da base de dados. Estes valores são perfeitamente aceitáveis, visto que o disco duro da máquina onde está implementado o sistema é de 80 Gb de capacidade e a sua instalação base apenas necessitou de 5.5 Gb. Mesmo a muito longo prazo esta base de dados, no cenário actual de VLAN's, o espaço de armazenamento em disco será sempre suficiente. É de observar que este é o valor máximo que se armazena, pois se eventualmente alguma VLAN definida estiver sem actividade, o PMACCT não captura pacotes dessa rede e como tal não necessita de efectuar registo em relação a essa VLAN, o que reduz a quantidade de registos. BWStat Este é um portal Web, escrito em PHP que serve para visualizar informação do PMACCT. Para o aceder, possui uma página de autenticação para acesso do utilizador 'admin', que é criado e definida a sua password ao configurar o portal para colocar on-line. Assim, neste front-end para o PMACCT, apenas foi necessário definir as configurações da base de dados MySQL a aceder para leitura dos dados a apresentar. De seguida, definiram-se os IP's a ler da base de dados e para este caso em concreto definiram-se as gamas de cada VLAN interna existente, sendo que é o tráfego destas que se pretende verificar. Relatório.Estágio.Final.odt Página 34/40

35 A sua utilização é extremamente simples, permite adicionar ou remover utilizadores para o seu acesso e também permite adicionar ou remover hosts para apresentar na página principal, ou seja, no caso implementado cada host vai ter a gama de rede de cada VLAN existente, sendo necessária a sua edição caso se alterem os endereços, adicionem ou removam VLAN's. Para mais detalhes sobre esta situação, consultar o manual de procedimentos do monitor de tráfego, que se encontra no anexo 8. Conclusões e resultados O monitor de tráfego encontra-se actualmente a trabalhar na rede do IPN e o seu funcionamento revelou-se útil, pelo que os dois modos de contabilização estão dar os resultados pretendidos. Ou seja, já houve situações em que se notaram discrepâncias no uso da rede e com o uso do NTop facilmente se detecta a pessoa ou grupo de trabalho que está a causar o problema. Assim sendo, e dependendo do tipo de utilização, é possível à USIC decidir acções acertadas de modo a resolver da melhor maneira o problema em questão. Quanto ao PMACCT, regista todo o tráfego à entrada e à saída (e apresenta o total destes dois), permite consultar numa data à escolha a quantidade de tráfego consumido em cada VLAN ou na prática em cada laboratório. Esta ferramenta pode ser usada para racionalizar os custos do aluguer do circuito dedicado para Internet, entre os vários laboratórios do IPN. Caso se venha a verificar no futuro a necessidade de classificar e priorizar o tráfego para a ligação ao exterior, esta pode ser efectuada de vários modos e recomenda-se num de dois pontos: na Firewall ou no Router de acesso ao exterior (caso este permita classificar tráfego). Isto depende muito da política a implementar nessa classificação, pois caso se defina QoS por utilizador terá de ser na Firewall, uma vez que o Router apenas vê as VLAN's. De modo a verificar que tipo de tráfego se consome mais no IPN, será necessário recorrer ao NTop com alguma frequência, pois apenas apresenta informação relativa ás últimas horas. Neste pode-se verificar em quantidade e percentagem o tráfego mais usado, que geralmente são HTTP, DNS e . No entanto é normal que haja outros protocolos que sejam frequentes e devem ser tidos também em consideração. A utilização da máquina usada para este trabalho como classificadora também chegou a ser ponderada pela USIC, mas como teria de adicionar mais um ponto crítico (de passagem) na rede, o recomendado é que essa classificação seja realizada num dos pontos referidos. Do mesmo modo que os servidores instalados anteriormente a este, procedeu-se a um backup total da máquina e ás suas actualizações periódicas, como descrito no anexo 9. Relatório.Estágio.Final.odt Página 35/40

36 Conclusões Finais Com este Estágio foi possível adquirir experiência profissional na área de administração e gestão de sistemas e redes, beneficiando o contacto com uma grande variedade de tecnologias recentes e emergentes da actualidade, com principal destaque para ambientes Linux. Para além da implementação, instalação e configuração de serviços ainda foram desenvolvidas duas aplicações em PHP que foram elaboradas à medida das necessidades. Importante também foi a possibilidade de trabalhar dentro de uma equipa com grande estado de espírito, lidar com outros colegas, trocar ideias, discutir problemas e tomar decisões importantes. Espera-se que todos os serviços implementados ofereçam valor interno ao IPN e que assim continuem no futuro. A equipa USIC possui agora mais ferramentas de apoio e suporte aos seus utilizadores, que são os colaboradores do IPN e as pessoas que o frequentam. Os objectivos de todo o projecto foram cumpridos e finalizados com sucesso. Resta observar que a documentação elaborada para a sua manutenção pode ser essencial para o seu futuro e deve ser actualizada sempre que haja modificações aos sistemas. Documentação essa que se encontra em anexo a este documento. Foi elaborada de maneira a dar a conhecer as resoluções mais eficientes aos problemas mais comuns, isto quer dizer que a sua consulta presume-se que seja por alguém da USIC e que obviamente está familiarizado com administração de sistemas e também com a rede interna do IPN. Relatório.Estágio.Final.odt Página 36/40

37 Referências [1] - Formato dos Relatórios de Estágio, A. Dias de Figueiredo, Disciplina de Comunicação e Profissão, DEI-FCTUC [2] - Acedido em: 12/11/2007 [3] - Acedido em: 14/11/2007 [4] - Acedido em: 19/11/2007 [5] - Acedido em: 19/11/2007 [6] - Acedido em: 10/12/2007, as secções: Features, FAQ, man chilli. [7] - Acedido em: 10/12/2007 [8] - Acedido em: 10/12/2007 [9] - Acedido em: 10/12/2007 [10] - Acedido em: 14/12/2008 [11] - Acedido em: 09/01/2008 [12] - Acedido em: 15/01/2008 [13] - Acedido em: 15/01/2008 [14] - Acedido em: 15/01/2008 [15] - RoamAbout R2 - Installation Guide [16] - RoamAbout - Hardware Installation Guide [17] - Acedido em: 31/01/2008 [18] - Acedido em: 31/01/2008, as secções Documentation, Bugs & Features, Articles & FAQ [19] - Acedido em: 31/01/2008, As secções: Mail List, Wiki, Software->Features, FAQ Relatório.Estágio.Final.odt Página 37/40

38 [20] - Acedido em: 03/04/2008 [21] - Acedido em: 09/04/2008 [22] - Acedido em: 29/04/2008 [23] - Acedido em: 14/05/2008 [24] - Acedido em: 14/05/2008 [25] - Acedido em: 14/05/2008, As secções: overview, docs->usagenotes, Monitoring [26] - Effective Traffic Measurement using ntop Acedido em: 14/05/2008 [27] - Acedido em: 05/06/2008, As secções: Overview, FAQs, config-keys [28] - Acedido em: 06/06/2008 [29] - Acedido em: 17/06/2008 Relatório.Estágio.Final.odt Página 38/40

39 Acrónimos AP - Access Point, também conhecido como estação base. CDP - Cabletron Discovery Protocol, proprietário da Enterasys para acesso aos seus AP's. CGI - Common Gateway Interface, script tipicamente escrito em Perl e que é executado num servidor Web. CUPS - Common Unix Printing System DHCP - Dynamic Host Configuration Protocol HTML - HyperText Markup Language IDS - Intrusion Detection System IP - Internet Protocol IPP - Internet Printing Protocol MAC - Media Access Control, endereço de layer 2 (ligação lógica). NAT - Network Address Translation NTop - Network Top PAM - Pluggable Authentication Modules, sistema de autenticação básica em sistemas Unix. PCMCIA - Personal Computer Memory Card International Association, formato de placas de hardware vulgarmente suportadas em computadores portáteis. PDA - Personal Digital Assistant PDF - Portable Document Format PHP - Hypertext Preprocessor, linguagem de programação open-source. PJL - Printer Job Language, protocolo desenvolvido pela Hewlett-Packard para comunicar directamente com as impressoras. PMACCT - Promiscuous Mode IP Accounting RADIUS - Remote Authentication Dial In User Service RAM - Random Access Memory RRD - Round Robin Database Relatório.Estágio.Final.odt Página 39/40

40 RSA - Rivest, Shamir, Adleman algoritmo de encriptação de chave pública, com nome em referência aos seus autores. SHA-1 - Secure Hash Algorithm, função de hash usada para verificação de integridade de dados. SNMP - Simple Network Management Protocol, usado para obter dados estatísticos e configurar remotamente equipamento de rede. SO - Sistema Operativo SQL - Structured Query Language SSID - Service Set Identifier, também conhecido por nome da rede Wireless. SSL - Secure Sockets Layer TLS - Transport Layer Security, protocolo de criptografia usado em conjunto com o SSL. URI - Uniform Resource Identifier VLAN - Virtual Local Area Network, LAN lógica virtual que pode ser definida entre vários Switchs físicos e portas físicas diferentes. QoS Quality of Service WEP - Wired Equivalent Privacy WiFi - Wireless Fidelity, consorcio de redes Wireless que define normas e regulamentos universais de modo a fornecer interoperabilidade entre redes Wireless. WPA - Wi-Fi Protected Access, modo de acesso seguro a redes Wireless, sucessor do vulnerável WEP. Relatório.Estágio.Final.odt Página 40/40

41 A1.R1 Anexo 1 Título: Estudo da rede Wireless inicial do IPN Contacto: André Ribeiro Estagiário ajoao@ipn.pt Controlo de versões Ref. Data Alterações Responsável Versão inicial do documento, resultado final das tarefas T1, T2 e T3 da Actividade Revisão com objectivo de inserir o documento num anexo do relatório de estágio final. Alguma informação interna do IPN foi omitida, assim como IP's, gamas de rede, etc. André Ribeiro André Ribeiro

42 Introdução Serve este documento para descrever o estudo efectuado à rede Wireless existente no Instituto Pedro Nunes (IPN) antes da implementação de tickets temporários, que passa por verificar e quantificar o equipamento, a sua localização, as configurações da rede e dos Access Points (AP's) e finalmente efectuar um estudo sobre os actuais métodos de acesso implementados e a sua segurança. Espera-se de futuro que se tenha em conta a matéria estudada neste documento, pois para além de dar a conhecer o equipamento a usar, estuda o local a implementar a rede Wireless e os métodos de acesso existentes até então. O objectivo desta actividade é alargar a rede a todo o IPN e criar um sistema de gestão de credencias temporárias para acesso à rede Wireless. Será importante também manter em paralelo um acesso seguro e fixo para servir os colaboradores do IPN. Rede Wireless no IPN Os Access Points (AP s) existentes actualmente no IPN já foram adquiridos há algum tempo e são 8 no total. Desses 8 apenas 2 se encontram em utilização, um em cada edifício, localizados ambos no segundo piso, numa das salas centrais e junto à janela do lado do corredor, de modo a ficarem num sítio mais central possível de cada piso. Apenas estão nestas posições porque servem só alguns colaboradores que estão relativamente perto desses AP's. A solução Wireless a implementar no IPN apenas diz respeito aos dois edifícios do IPN, não estando prevista para já uma implementação no novo edifício da IPN-Incubadora. Cada edifício é composto por três pisos mais a cobertura. Independentemente das salas dos dois edifícios estarem ocupadas ou não, será importante ter uma rede sem fios com cobertura em todas elas, pois um dia mais tarde pode ser sempre necessário vir a ter rede Wireless em qualquer local dentro da instituição. Descrição dos Access Points RBTR2-A Enterasys RoamAbout Wireless Network Estes AP s apesar de terem já algum tempo de vida, foram desenhados de modo a suportarem upgrade para novas normas Wireless Fidelity (WiFi) que eventualmente podem surgir. Trabalham com uma placa de rádio Personal Computer Memory Card International Association (PCMCIA) WiFi que pode ser substituída por uma que seja mais recente, desde que seja compatível com o próprio hardware RBTR2-A da gama RoamAbout R2 da Enterasys. As placas que os acompanham, são as compatíveis RoamAbout a/b/g e foram fabricadas em específico para trabalhar com o AP RBTR2-A. Estas placas possuem um conector MMCX fêmea para ligação a uma antena externa. A1.R1 Anexo 1.odt Página 2/7

43 Principais especificações dos AP s: - Suporte total das normas a, b/g; - Modo repetidor ou AP -> Point-to-Point ou Point-to-Multipoint; - Segurança: 802.1x, Extensible Authentication Protocol (EAP), Wired Equivalent Privacy (WEP); - Power over Ethernet, PoE apenas será necessário levar até o AP o cabo de rede categoria 5e, ficando o transformador eléctrico no bastidor; - Roaming (hard-handoff, cliente muda de AP de um modo transparente); - Wireless Virtual Local Area Network (W-VLAN); - Autenticação por Remote Authentication Dial In User Service (RADIUS). Figura 1 - AP Enterasys RoamAbout R2, placa rádio PCMCIA, transformador e filtro para PoE. Comparação a/b/g [1] Protocolo Data de lançamento Frequência Débito típico Débito Máx. Modulação Alcance Indoor Alcance Outdoor a GHz 23 Mbit/s 54 Mbit/s OFDM ~35m ~120m b GHz 4.3 Mbit/s 11 Mbit/s DSSS ~38m ~140m g GHz 19 Mbit/s 54 Mbit/s OFDM ~38m ~140m Gestão do AP Apesar de suportar gestão por um navegador Web, esta não vem activada por defeito, pois o fabricante fornece uma aplicação (AP Manager) que realiza todas as tarefas de administração do AP, desde que exista conectividade para este, ou também directamente através da porta série RS-232. Essa aplicação fornecida em CD, encontra-se também desactualizada (v10.01), pelo que se descarregou a última versão (v11.10). O acesso às suas configurações também pode ser efectuado por consola Telnet (Clear Text, pouco seguro) ou por SSH (Secure Shell, com certificados), pelo que o método mais recomendado será este último, até porque permite configurar todas as opções disponíveis. Assim sendo e de modo a não sobrecarregar muito os AP's, não será necessário activar o acesso por navegador Web, ficando apenas o serviço SSH activado. Verificou-se também no site do fabricante, que existia uma versão mais recente de firmware e antes de qualquer teste, essa nova versão ( ) foi carregada, que data de Fevereiro de O firmware existente era o de origem, versão O mesmo update foi efectuado aos restantes AP s antes de os colocar em utilização. A1.R1 Anexo 1.odt Página 3/7

44 Configuração inicial dos AP's Os AP s em uso actualmente no IPN estão configurados de um modo básico, não tendo qualquer mecanismo de segurança nas suas configurações. A segurança no acesso à rede é garantida para lá do AP, na rede interna do IPN, nomeadamente pela ligação a um túnel VPN (Virtual Private Network), que será descrito mais à frente. Está activado a definição do país onde está instalado o AP, que é Portugal, isto para operar apenas nos canais de rádio de redes WiFi que são permitidos por lei. As restantes configurações principais são as por defeito e mesmo o seu IP apenas serve para manutenção, pois a atribuição e gestão de configurações de rede são da responsabilidade de um servidor, como iremos ver de seguida. Ao pesquisarmos uma rede WiFi no IPN surge, se estiver dentro do alcance, a rede com o Service Set Identifier (SSID): 'IPN'. Depois de conectar a essa rede, é atribuído por DHCP um endereço IP interno, que não tem acesso directo à rede local. Apenas permite uma ligação directa à VPN em uso no IPN. Esta depois de ligada com sucesso é que fornece acesso à rede local e consequentemente à Internet. Deste modo qualquer utilizador que eventualmente se ligue a esta rede ficará com a ligação limitada, enquanto não ligar a VPN em funcionamento. Para que isso aconteça, existe a máquina Firewall, que é também a máquina que recebe as ligações VPN e que permite tráfego de DNS para os utilizadores da rede Wireless antes destes criarem a sua ligação. Ilustração do cenário descrito Figura 2 Cenário da rede Wireless inicial. A1.R1 Anexo 1.odt Página 4/7

45 Análise dos sistemas de segurança O acesso à rede do IPN através da rede Wireless, é efectuada através de uma VPN, em que é usada a solução openvpn [5]. Este, para além de ser open-source, tem a vantagem de ser suportado na grande maioria dos SO's (Sistema Operativos) actuais e a sua instalação e configuração é relativamente simples. Os AP's necessitam de algum cuidado de segurança a nível físico e pode-se verificar que se encontram sempre do lado de dentro das salas ou em sítios de difícil acesso físico (numa parede alta, por ex.). Não só para os salvaguardar de furtos, mas também para evitar utilizações mal intencionadas, isto porque podem ser directamente acedidos através da porta série R-232 ou através da porta Ethernet. No entanto é necessário usar a aplicação AP Manager para aceder por Ethernet, uma vez que a gestão por interface Web se encontra desactivada. openvpn Solução open-source de VPN que se usa actualmente no IPN. Permite autenticação por dois modos distintos: chave estática - Pre-Shared Key (PSK); ou por TLS SSL/TLS (Secure Sockets Layer/Transport Layer Security) com certificados. Por chave estática, basicamente existe um par de chaves pública/privada igual no servidor e em todos os clientes, que é sempre usada na encriptação do túnel da VPN, daí chamar-se chave partilhada e o tipo de encriptação é conhecida como simétrica. Deste modo, torna-se pouco viável a sua distribuição, visto que a chave era de conhecimento geral. O acesso preferencial e usado no IPN é por TLS, com certificados. Neste caso a autenticação é feita nos dois lados, cliente e servidor, ou seja, ambos têm de apresentar o seu certificado através de um handshake para tal, que consiste em mostrar de um modo seguro apenas a chave pública de cada um à outra parte. Assim, o cliente e o servidor irão usar sempre modos de encriptação/desencriptação diferentes um do outro, em que se baseiam na sua própria chave privada e chave pública do peer remoto, nunca necessitando de transportar a sua chave privada. Este método de encriptação é conhecido como assimétrico. A máquina que recebe todas as ligações do openvpn encapsula todo o tráfego para um túnel VPN. Assim essa máquina apenas aceita tráfego do tipo DNS (para resolver o nome 'openvpn.ipn.pt') e openvpn. Para conectar ao openvpn é necessário ter certificados válidos, o que faz com que só utilizadores autorizados obtenham ligação à rede Wireless existente. É preferencial ao IPSec (Internet Protocol Security) na medida em que é mais fácil de implementar, não sendo muito mais pesado computacionalmente para o servidor como para os clientes. O IPSec para além de ser mais complexo na sua configuração, apresenta também algumas dificuldades em atravessar redes com Network Address Translation (NAT) em algumas circunstâncias. No entanto, o openvpn apenas disponibiliza as funcionalidades básicas de uma VPN e não é compatível com o protocolo IPSec. O IPSec foi desenhado como uma modificação ao IP dentro do Kernel do SO, logo cada um utiliza uma implementação A1.R1 Anexo 1.odt Página 5/7

46 diferente do IPSec, apesar ser compatível entre diferentes SO's. Ao contrário, o openvpn apresenta-se como uma solução mais portátil, pois usa para encriptação os protocolos SSL/TLS que são suportados por praticamente todos os SO's disponíveis hoje em dia. O acesso ao openvpn do IPN não é efectuado unicamente para a rede Wireless que actualmente está em funcionamento, mas também aceita ligações a partir do exterior. Isto para que os seus colaboradores obtenham acesso à rede interna do IPN de um modo seguro e transparente, a partir de qualquer ponto da Internet. Assim, mesmo que se implemente outro tipo de acesso à rede Wireless para os seus colaboradores, o openvpn terá de permanecer activo. Acesso Como referido, para um utilizador se ligar na VPN do IPN tem de possuir o devido certificado, chave privada/pública e o ficheiro de configuração. Aqui se encontra o principal entrave para esta solução de acesso à rede Wireless, pois sempre que adiciona um utilizador é necessário entregar-lhe os respectivos ficheiros de um modo seguro. Para uma comunidade com poucos utilizadores esta solução funciona bem, enquanto a equipa da USIC for criando as devidas chaves e certificado para cada novo utilizador e as entregar devidamente a cada um, mas se de futuro estes aumentarem muito, a solução actual não se apresenta muito escalável. Para cada novo utilizador a adicionar no openvpn, usam-se scripts que geram automaticamente todos os ficheiros de configuração a usar, respectivo par de chaves e certificado. Entrega-se a este por com os ficheiros dentro de um.zip encriptado com uma password, que posteriormente é entregue por SMS. Depois basta ter instalado no sistema o openvpn e, segundo as instruções para o SO instalado no cliente, executar a sua ligação. As instruções de configuração do openvpn para Windows e Linux encontram-se disponíveis numa página Web de suporte do IPN. Em ambos os SO's a sua configuração é efectuada em poucos passos, não sendo muito complexa e demorada. É no entanto necessário, o pedido do certificado, chaves de acesso e ficheiro de configuração à equipa USIC. Para cada utilizador a ser adicionado no openvpn, é necessário definir a zona correspondente à VLAN do laboratório a qual este pertence. A definição de zonas serve para atribuir um endereço IP fixo ao utilizador, dentro da gama de endereços da zona seleccionada, isto quer dizer que a diferentes utilizadores são atribuídos IP's diferentes, consoante os laboratórios a que pertencem. Isto faz com que fiquem, de um modo transparente, dentro da rede interna da sua área e com os mesmos acessos que ai possui. A1.R1 Anexo 1.odt Página 6/7

47 Conclusões O que existe actualmente da rede Wireless não é uma solução que satisfaça as necessidades do IPN na totalidade, pois ainda não há um modo de acesso definitivo. Apesar de alguns utilizadores já usarem a infra-estrutura, ainda não existem senhas temporárias para aceder à rede nem cobertura total nos dois edifícios, o que pode dar valor ao IPN, uma vez que existem muitos utilizadores temporários, convidados, formandos, etc.. Os AP s da Enterasys apesar de não serem de última geração conseguem satisfazer as necessidades que a instituição precisa e revelaram boa capacidade de configurações e suporte de protocolos. Como são 8 no total, espera-se que estejam em número suficiente e após uma primeira análise algo superficial, de testes de cobertura, pensa-se que 3 ou 4 AP s por edifício serão suficientes, estando sujeitos ainda a algum estudo de cobertura. O facto de suportarem PoE é bastante bom para esta situação, pois assim no limite só será preciso passar cabos de rede e colocar algum suporte numa parede, não sendo necessário instalar tomadas eléctricas junto dos AP's. Quanto ao acesso pelo openvpn, revelou-se bastante seguro pelo que fica como potencial hipótese de se implementar para acesso dos colaboradores do IPN à rede Wireless. Isto porque, para além de não ser muito difícil de configurar, os utilizadores já conhecem a ferramenta. No entanto, os AP's em uso carecem de algumas configurações básicas modificadas, que irão ser descritas ao longo da implementação do sistema. Referências [1] /11/2007 [2] - [3] - [4] - [5] - [6] - [7] - (precisa de registo) - Documentação em papel e PDF incluídos nos CDs dos AP's. A1.R1 Anexo 1.odt Página 7/7

48 A1.R2 Anexo 2 Título: Análise de sistemas open-source de geração de chaves temporárias para redes Wireless Contacto: André Ribeiro Estagiário ajoao@ipn.pt Controlo de versões Ref. Data Alterações Responsável Versão inicial do documento, resultado final das tarefas T4 e T5 da Actividade Simplificação da descrição do cenário de testes de soluções. Melhorias a nível da escrita Revisão com objectivo de inserir o documento num anexo do relatório de estágio final. Alguma informação interna do IPN foi omitida, assim como IP's, gamas de rede, etc. André Ribeiro André Ribeiro André Ribeiro

49 Introdução As soluções de software a analisar durante esta tarefa pretendem-se em primeiro lugar que sejam open-source, pois o IPN não pretende ter mais algum tipo de gastos com soluções comercias, para além do que já teve com a aquisição dos Access Points (AP's). Em segundo, espera-se que corra em ambiente Linux e que seja o mais genérica possível, isto é, compatível com as mais recentes versões de ferramentas possíveis a usar (base de dados, protocolos de autenticação, servidor Web, etc.). Também é desejável que esteja numa fase estável e actualmente com boa documentação. Pretende-se então encontrar uma ferramenta que tenha em vista a concretização dos objectivos gerais da primeira tarefa do estágio, que são a criação de chaves temporárias para convidados terem acesso à rede Wireless do IPN. O objectivo será criar contas de acesso que expiram automaticamente X horas após a primeira utilização. Também é necessário ter em conta que após a entrega destas contas de acesso, o convidado não deverá ter dificuldades em ligar-se à rede, independentemente do equipamento e Sistema Operativo (SO) que estiver a usar. Deste modo, a maneira mais simples será ter um Captive Portal [1], que não é mais do que um modo de autenticação por página Web que lhe é apresentado (redireccionado automaticamente) se tentar aceder à Internet através de um navegador Web. Para testar as aplicações encontradas foi necessário configurar uma máquina existente, em que foi instalado o SO Gentoo Linux. Esta, apesar de ser um pouco antiga, apresenta os requisitos mínimos para cumprir os objectivos, que se esperam não ser computacionalmente muito pesados. É no entanto recomendável que se adapte a uma máquina de produção, isto é, que a sua operacionalidade e disponibilidade seja elevada e que garanta alguma segurança dos seus dados. Para tal, foram adquiridos dois discos rígidos de igual capacidade para trabalharem em modo RAID-1 (Redundant Arrays of Independent Disks em modo mirror, com redundância de dados entre os dois), para assegurar a disponibilidade do serviço em caso de falha de um deles. Foi necessário instalar duas placas de rede, pois no cenário que se pretende implementar a máquina possivelmente funcionará como Router (encaminhador de tráfego). A1.R2 Anexo 2.odt Página 2/7

50 Soluções encontradas Após discussão entre os colegas da USIC do IPN, verificou-se a existência do NoCat [2] e WiFiDog [3], pelo que se exploraram estes em primeiro lugar. Depressa se concluiu que o NoCat já não está muito actualizado, a sua documentação era pouca e nunca chegou a ter uma release final. Mesmo assim verificou-se que o NoCat existe em duas aplicações, cada uma delas com as seguintes funcionalidades principais: - NoCatAuth: Captive Portal [1] para autenticação de clientes numa base de dados MySQL; escrito em Perl e em C; controlo de largura de banda por utilizador; controlo de acesso por Firewall; verificação do estado do utilizador. - NoCatSplash: sucessor do NoCatAuth, implementa todas as suas funcionalidades; apenas escrito em C, o que o torna mais leve; possibilidade do utilizador apenas ler uma página de splash com as condições de utilização e um botão para as aceitar. Apesar de na sua documentação (apenas existente junto aos ficheiros de instalação) ser claro que ainda está em fase de desenvolvimento, não existe nenhuma actualização desde meados de 2005, pelo que não se chegou a testar esta solução. Alias, o WiFiDog foi inspirado no NoCat e surgiu de modo a implementar mais funcionalidades e colmatar certas limitações. Outras soluções open-source de Captive Portals [1] existentes e que não foram testadas pelas razões explicadas são as seguintes: - PfSence [4]: corre em freebsd através de um live CD ou instalado a partir do mesmo CD. Apesar de implementar muitas funcionalidades e de aparentemente preencher os requisitos, não se adapta à solução que se pretende em Linux. É política no IPNlis manter os servidores com a distribuição Gentoo Linux, pois torna-se mais prático de trabalhar uma vez que há mais conhecimentos de gestão e configuração deste sistema. - Wilmagate [5]: este projecto open-source parece que também já não está activo, pois todos os links existentes para a documentação não se encontram disponíveis; apesar de referir que suporta vários modos de autenticação não especifica nenhum, dizendo apenas que é feita manualmente por sockets num determinado porto TCP (Transport Control Protocol). - SweetSpot [6]: baseado no ChilliSpot, mas trabalha apenas em layer 3 (IP:porto) em vez de layer 2 (MAC); mantém uma lista de IP's com acesso e bloqueia os restantes; como também se encontra numa fase inicial de desenvolvimento, ainda não implementa todas as suas funcionalidades esperadas, assim como a segurança da autenticação dos utilizadores ainda não é fiável. Para além destas soluções, surgiram também outras mas de âmbito comercial, as quais não fazem parte deste estudo, pois não são pretendidas pelo IPN. As soluções que efectivamente foram testadas são o WiFiDog e o ChilliSpot, sendo as que se revelaram mais apropriadas para implementar, pelo que se descreve cada uma delas de seguida. A1.R2 Anexo 2.odt Página 3/7

51 WiFiDog O WiFiDog é um sistema completo de Captive Portal que tem como objectivos controlar e verificar o acesso de utilizadores a hotspots (zonas Wireless) públicos e que permite uma gestão centralizada desses utilizadores, controlo da largura de banda e de tráfego de cada um. Inicialmente pensado para ser uma alternativa ao NoCat, o WiFiDog é mais leve e permite uma gestão muito mais completa dos hotspots. É composto por dois módulos lógicos que comunicam um com o outro: o WiFiDog gateway (cliente) e o servidor de autenticação (WiFiDog auth). A gateway foi desenhada de modo a ser flexível, escrita em C e permite ser instalada dentro do próprio firmware de alguns AP's compatíveis com WRT (firmware opensource, que corre numa vasta gama de AP's mas não nos da Enterays existentes no IPN), assim como em qualquer distribuição de Linux e pode correr na mesma máquina que o WiFiDog Auth. Já o WiFiDog Auth ainda se encontra em fase desenvolvimento, mas as principais funcionalidades já estão implementadas. Este foi escrito em PHP (Hipertext Preprocessor) e a base de dados que usa por defeito para gestão de utilizadores é PostgreSQL unicamente. O WiFiDog Gateway usa regras da Firewall (iptables/netfilter) para controlar o acesso à rede por parte do utilizador. Assim quando este se liga ao AP e tenta abrir uma página Web é redireccionado pela gateway de um modo transparente para uma página de autenticação que se encontra no WiFiDog Auth. Aqui o utilizador pode fazer login (se já tiver conta) ou signup que permite registar-se. O processo de registo consiste em identificar o utilizador pelo . Assim introduz-se o , uma password e o servidor envia um para confirmação. O utilizador tem 20 minutos de acesso livre à Internet para confirmar o recebido e depois de confirmado pode fazer login e a sessão já não expira. É deste modo que o WiFiDog trabalha por defeito e foi assim testado com sucesso, mas o que o IPN pretende seria por exemplo autenticar utilizadores já existentes em que haja possibilidade de expirar a sua sessão após X horas de utilização da rede Wireless. O Gateway e o Auth falam um com o outro frequentemente para actualizar estatísticas como o tempo de utilização, débito usado, quantidade de tráfego por utilizador e para saber se o utilizador ainda está ligado. Sendo a solução por defeito não desejável, por motivos já referidos, procurou-se modificar o modo de autenticação para um servidor RADIUS (Remote Authentication Dial In User Service). Depois de efectuada a alteração na página de administração do WifiDog Auth, este deixou de responder, pois certamente não estava correctamente configurado. A documentação existente para essas configurações ainda não existe, pelo que não foi possível autenticar desse modo. Os requisitos principais instalados previamente foram: Apache-2, PHP5, PostgreSQL, iptables. O gateway foi o WiFiDog e o servidor de autenticação foi descarregado em 28/11/2007 através do Subversion para a ligação oficial da versão de desenvolvimento disponível. A1.R2 Anexo 2.odt Página 4/7

52 Funcionalidades WifiDog Gateway: - Verifica a conectividade de um utilizador através de um ping periódico a este; - Implementa uma Firewall de controlo de acesso que pode ser facilmente configurada no ficheiro de configuração; - Liga-se a servidores de autenticação secundários, caso um deixe de responder; - Configurado para operar numa interface de rede e detecta as suas definições automaticamente; Funcionalidades WifiDog Auth: - Dois modos de portal: modo splash e modo normal; - Personalização individual de cada nó (AP); - Não é necessário configurar paths no servidor Web (Apache), apenas no ficheiro de configuração; - Pode importar utilizadores do NoCat; - Utilizadores podem criar contas sem intervenção do administrador (20min de acesso); - Utilizadores podem modificar a sua password ou pedir uma nova; - tem de ser válido mas não é apresentado no portal; - Impossibilidade criar utilizadores com s duplicados; - Estatísticas de utilização por utilizador e top10's (consumo de tráfego, duração das ligações, endereço MAC, nº de utilizadores, etc.), representação gráfica; - Estado da rede e dos nós (AP's); - Suporte multilíngua; - Vários modos de autenticação, incluindo localmente no PostgreSQL; Como podemos observar o WiFiDog foi feito a pensar em utilizadores que fazem o próprio registo e serem identificados não só pelo endereço MAC, mas também para efectuar um controlo sobre os utilizadores que abusam da ligação. Está previsto o desenvolvimento de uma área de gestão de utilizadores antes da versão 1.0 do Auth. O suporte para WPA também é suportado mas ainda não existe documentação sobre como o configurar nem no servidor nem no cliente. ChilliSpot O ChilliSpot [7] é mais um Captive Portal construído para Wireless LAN's (Local Area Network s) que faz com que os utilizadores dessa rede tenham que se autenticar via Web Browser, isto juntamente com um servidor Web e um servidor de autenticação RADIUS podem situar-se na mesma máquina que o ChilliSpot ou não. Suporta qualquer tipo de servidor RADIUS e optou-se por usar o freeradius devido à sua simplicidade de uso e boa documentação. Também na Wiki da Gentoo existe um manual de como configurar o ChilliSpot com o freeradius e MySQL [8]. Este software foi bastante simples de instalar e de configurar assim como os seus requisitos, nomeadamente o freeradius e o MySQL. Foi necessário recompilar o kernel com o módulo TUN/TAP instalado, para criar a interface de rede virtual que o ChilliSpot irá usar para filtrar tráfego. Depois de configurado para trabalhar na máquina em questão e adicionado o servidor RADIUS localmente, testou-se com um utilizador adicionado manualmente no ficheiro de configuração do RADIUS, apenas para teste. Depois disso, desactivou-se a autenticação pelo A1.R2 Anexo 2.odt Página 5/7

53 ficheiro de utilizadores do RADIUS e usou-se o MySQL. Após algum tempo a explorar o funcionamento do freeradius e do MySQL, foi possível com os utilizadores adicionados manualmente na base de dados, efectuar login correctamente no ChilliSpot. Ao contrário do WiFiDog, o ChilliSpot não bloqueia o acesso aos utilizadores através da Firewall, mas sim na interface em que usa o endereçamento da rede interna (zona Wireless) que é uma interface virtual e controlada pela própria aplicação. Isto porque a interface física da máquina tem necessariamente de ser configurada sem IP. Assim essa interface irá ser também o servidor DHCP (Dynamic Host Configuration Protocol) dos utilizadores que se irão ligar aos AP s que ai se encontram. Na configuração do ChilliSpot é possível definir uma lista de hosts ou de URL's (Uniform Resource Locators) aos quais pode-se dar acesso sem o utilizador estar autenticado. Funcionalidades do ChilliSpot: - Dois métodos de autenticação: UAM - Universal Access Method: o utilizador recebe um IP do ChilliSpot (pelo seu DHCP) e ao abrir uma página num Browser é redireccionado para a página de autenticação; o servidor Web (Apache) recebe as credenciais do utilizador e envia-as encriptadas para o ChilliSpot que trata da autenticação com o freeradius; este consulta a base de dados MySQL e responde com uma mensagem do tipo 'access-accept' para o ChilliSpot se teve sucesso, caso contrário envia um 'access-reject'. WPA - Wireless Protected Access: a autenticação é tratada no AP (este tem de suportar WPA) e consequentemente redirecciona para o ChilliSpot; neste modo, toda a comunicação entre o cliente Wireless (do utilizador) até ao AP é encriptada; não é necessário o servidor Web; o utilizador terá de ter instalado um suplicante e as suas configurações adaptadas ao tipo de ligação. - Compatível com qualquer AP para o modo UAM; para WPA os AP's têm de suportar este protocolo nativamente. - Compatível com a maioria dos servidores RADIUS existentes. - Permite efectuar 'logout' se escrever 'exit' num Browser, surgindo a página para tal. - Se o endereço DHCP do utilizador não for renovado, o ChilliSpot faz 'logoff' desse utilizador, que por defeito é verificado de 30 em 30 minutos. Para configurar com o freeradius com o MySQL, apenas foi necessário modificar as credencias de acesso à base de dados num ficheiro de configuração, isto porque, por defeito o freeradius já vem pré configurado para se ligar a esta base de dados. Depois disto criou-se devidamente a base de dados no MySQL e assim foi possível testar a autenticação de utilizadores no ChilliSpot, sendo a sua criação e manutenção efectuada manualmente nessa base de dados. Como era de esperar, até este momento estas configurações foram apenas para testar o sistema e certamente serão modificadas para obter os objectivos esperados para produção, que é a gestão de utilizadores temporários. A1.R2 Anexo 2.odt Página 6/7

54 Conclusões Pouco tempo depois do ChilliSpot estar a funcionar sem problemas e dada a sua simplicidade e eficiência, decidiu-se que este seria a melhor solução a adoptar. Não só pelo facto de ser mais fácil a sua utilização, mas também por suportar praticamente todos os protocolos mais recentes e também os modos de autenticação mais comuns, para além de mais bases de dados. Com o WiFiDog acabou-se por não saber se era possível aceder à rede através de utilizadores predefinidos. O servidor de autenticação ainda está em fases de desenvolvimento e muitas das funcionalidades que possivelmente se podiam usufruir ainda estão em construção. Referências A1.R2 Anexo 2.odt Página 7/7

55 A1.R4 Anexo 3 Título: Procedimentos e configurações de manutenção da rede Wireless Contacto: André Ribeiro Estagiário ajoao@ipn.pt Controlo de versões Ref. Data Alterações Responsável Versão inicial do documento, resultado final das tarefas T6 da Actividade Revisão com objectivo de inserir o documento num anexo do relatório de estágio final. Alguma informação interna do IPN foi omitida, assim como IP's, gamas de rede, etc. André Ribeiro André Ribeiro

56 ÍNDICE SERVIÇOS NA MÁQUINA 'WIFI'...3 CONFIGURAÇÕES DE REDE...3 FIREWALL - IPTABLES...3 CHILLISPOT...4 FREERADIUS...5 PROCEDIMENTOS COMUNS...5 DESLIGAR UM UTILIZADOR MANUALMENTE...6 INSERIR UTILIZADOR 'ADMIN' NA BASE DE DADOS...6 ACEDER À CONSOLA DE ADMINISTRAÇÃO DE UM AP...7 INSERIR UTILIZADOR TEMPORÁRIO MANUALMENTE NA BASE DE DADOS...7 CONSULTAR INFORMAÇÃO ADICIONAL DO ACESSO DOS UTILIZADORES TEMPORÁRIOS...8 UTILIZADOR 'ADMIN' PERDEU A SUA PASSWORD...9 UTILIZADOR TEMPORÁRIO PERDEU A SUA PASSWORD...9 PÁGINA DE ADMINISTRAÇÃO DE CONTAS...10 DESCRIÇÃO DO FUNCIONAMENTO...10 CONFIGURAÇÃO DOS ACESSOS...12 A1.R4 Anexo 3.odt Página 2/12

57 Serviços na máquina 'wifi' A máquina usada para executar os serviços requiridos para a rede Wireless encontra-se no edifício central do IPN, dentro da área técnica junto ao bastidor. Os principais serviços que ai correm são os seguintes: Apache2, ChilliSpot, iptables (script de regras /etc/init.d/firewall.iptables), MySQL, radiusd (freeradius), SSH e o Syslog-ng para além das duas interfaces de rede existentes. Os serviços encontram-se prontos a serem carregados ao arranque, para que no caso de um reboot inesperado o tempo de recuperação do serviço seja o menor possível. Para isso configurou-se os serviços com o comando 'rc-update'. Configurações de rede Como a máquina se encontra directamente na rede externa, foi-lhe atribuído o seguinte IP público: <IP-wifi.ipn.pt>, na interface ethx que acede directamente à Internet. A outra interface, ethy, foi configurada sem IP, pois é a interface virtual, ethv, que controla a rede Wireless, e é controlada pelo ChilliSpot. No entanto na interface ethy foi configurado um alias propositadamente para aceder à configuração dos AP's, que se efectua unicamente por SSH (Secure Shell) a partir da própria máquina, e que tem como endereço IP: <rede-gestão-aps>. Isto porque os AP's estão configurados nessa gama, com o último dígito a representar o nome do AP em questão, por exemplo, o AP-3 tem como endereço IP: <gama-rede-ap.3>. Quanto à interface virtual ethv, como é controlada pelo ChilliSpot, é configurada no ficheiro de configuração deste e é ai que está o servidor de DHCP da rede Wireless. Tem como endereço IP: <IP-servidor-rede-WiFi> e é nessa gama de classe A que os endereços IP são atribuídos aos utilizadores da rede Wireless. Para a configuração das interfaces físicas de rede, temos o seguinte ficheiro: /etc/conf.d/net #Configurar o IP publico config_ethy=( "<IP-wifi.ipn.pt> netmask <mascara-ip-wifi.ipn.pt>") #Indicar o default gateway routes_ethy=( "default via <gateway-externo>" ) # A ethx fica configurada sem IP, e um alias ethx:1 fica com o endereço para gestão dos AP's config_ethx=( " " "<IP-gestão-APs> netmask <mascara-gestão-ap>" ) Firewall - iptables Uma vez que a máquina se encontra acessível directamente a partir do exterior, é essencial protege-la com a Firewall iptables/netfilter. Assim optou-se por definir todas as politicas a DROP em primeiro lugar, e só depois permitir o que se pretende. As únicas permissões à entrada da máquina a partir da interface externa (que liga à Internet) são HTTP, HTTP/S (para A1.R4 Anexo 3.odt Página 3/12

58 obter o portal de gestão de contas temporárias) e SSH (a partir da rede interna do IPN). Á saída dessa interface, permite-se DNS, HTTP e Rsync (para os updates). Na interface interna (que liga à rede Wireless) permite-se à entrada HTTP, HTTP/S, DNS e o porto 3990 TCP (onde o ChilliSpot espera ligações). Já o tráfego em passagem (forward), é basicamente todo o que é permitido aos utilizadores da rede Wireless usufruírem depois de autenticados, e que é o seguinte: SSH, DNS, HTTP, HTTP/ S, SMTP, SMPT/S, POP3, POP3/S, IMAP, IMAP/S e tráfego openvpn com destino ao concentrador de VPN. Finalmente na tabela de NAT, foi necessário aplicar activação de NAT na interface externa, isto para os utilizadores da rede Wireless poderem ter acesso à Internet. Por último, acrescentou-se uma regra para que todos os pedidos de ligação à openvpn sejam mascarados para o destino da máquina concentradora da openvpn, que é o <IP-openvpn.ipn.pt>. O script de configuração e inicialização automática encontra-se em: /etc/init.d/firewall.iptbales. ChilliSpot A configuração desta aplicação é relativamente simples, apenas tem um ficheiro de configuração. Este serviço está configurado para trabalhar na interface de rede que liga à VLAN Wireless, que é a ethx. Descreve-se de seguida o seu ficheiro de configuração: /etc/chilli.conf # Define a gama de endereços a atribuir por DHCP aos clientes net <rede-wifi-interna> domain wifi.ipn.pt # É necessário definir este porto, para a possibilidade de enviar uma mensagem para o servidor # RADIUS do tipo 'disconnect' para banir um determinado utilizador coaport <porto-radius> # Obrigatório definir dois, é na própria máquina radiusserver radiusserver # Definir os endereços públicos dos servidores DNS dns1 <IP-externo-DNS-1> dns2 <IP-externo-DNS-2> # Chave do RADIUS - ChilliSpot radiussecret <password-do-radius> dhcpif ethx # Permite aos clientes resolverem DNS, apesar de não ligarem directamente aos servidores definidos uamanydns # Endereços a que se dá permissão de acesso sem autenticação (própria máquina e openvpn) uamallowed <IP-servidor-wifi-ethX>,<IP-openvpn.ipn.pt> # Localização do script PHP na máquina uamserver <URL-local-para-hotspotlogin.php> # Chave ChilliSpot Script PHP uamsecret <password-uam> A1.R4 Anexo 3.odt Página 4/12

59 freeradius Inicialmente este servidor RADIUS vinha configurado por defeito para trabalhar com uma lista de utilizadores adicionados manualmente num ficheiro, mas como não foi caso pretendido, esta opção foi desactivada e activou-se o uso de uma base de dados MySQL. Para além disso há que acrescentar que, como este servidor irá trabalhar na mesma máquina que o ChilliSpot, as definições de clientes manteve-se inalterada, e tem o seguinte aspecto: /etc/raddb/clients.conf client { secret = <password-do-radius> shortname = localhost nastype = other } As restantes configurações do freeradius prendem-se por activar um parâmetro que acciona um tempo de vida de um utilizador desde o seu primeiro login, o que o torna efectivamente temporário, e a activação de um campo para fazer com que os convidados apenas se façam login de um único dispositivo. De resto foi só necessário configurar o acesso local à base de dados do MySQL. De seguida estão as modificações realizadas, nos respectivos ficheiros: /etc/raddb/radiusd.conf #Adicionado um contador automático que faz a verificação do tempo limite do utilizador, a contar do seu #primeiro login. Caso nunca tenha entrado, o valor AcctSartTime na base de dados é NULL e o utilizador #é permitido, caso o seu 'Access-Period' seja superior a 0. modules {... sqlcounter accessperiod { counter-name = Max-Access-Period-Time check-name = Access-Period sqlmod-inst = sql key = User-Name reset = never query = "SELECT UNIX_TIMESTAMP() - UNIX_TIMESTAMP(AcctStartTime) FROM radacct WHERE UserName = '%{%k}' ORDER BY AcctStartTime LIMIT 1" }... } #Para descrição detalhada de cada uma destas opções, verificar a documentação no próprio ficheiro. Procedimentos comuns De seguida descreve-se de uma forma global, os procedimentos necessários para realizar as operações mais comuns no servidor da rede Wireless do IPN. Nota: o acesso por SSH à máquina wifi.ipn.pt só possível dentro da rede interna do IPN e assume-se que seja com o utilizador 'root'. A1.R4 Anexo 3.odt Página 5/12

60 Desligar um utilizador manualmente Usa-se um comando do freeradius. Para mais detalhes verificar o script criado logoff.sh, existente na pasta /root/. Como será de esperar, esta função apenas desliga o utilizador do sistema, mas não o caduca. Para tal deverá ser efectuado através do portal Web. Este comando foi implementado na página Web de administração de contas temporárias Wireless, sendo possível ai desligar o utilizador e consequentemente caduca-lo, isto é, fica com a duração de sessão com o valor zero. Inserir utilizador 'admin' na base de dados Este utilizador 'admin' serve apenas para se poder aceder à página de administração. É importante inserir a password com a função do MySQL PASSWORD(), pois é criada a hash, e o portal Web também vai comparar a mesma hash quando se verifica a password do 'admin'. A1.R4 Anexo 3.odt Página 6/12

61 Aceder à consola de administração de um AP O endereço IP que os AP's têm configurados, serve apenas para aceder à sua configuração por SSH, isto porque funcionam só como switchs entre os clientes Wireless e o servidor. Inserir utilizador temporário manualmente na base de dados Estes deverão ser sempre adicionados no portal, pois é especialmente para isso que foi criado. No entanto, serve para compreender como são adicionados nesse portal. A1.R4 Anexo 3.odt Página 7/12

62 Consultar informação adicional do acesso dos utilizadores temporários Existe muita informação de acesso que fica registada na base de dados e nos logs do freeradius, assim como datas e horas a que os utilizadores entram/saíram do sistema, endereços MAC dos clientes, endereços IP a eles atribuídos, etc. Assim, esses dados podem ser consultados da seguinte forma: No portal Web, foi desenvolvida a funcionalidade de visualizar a seguinte informação para os tickets caducados e respectivamente para cada sessão realizada: endereço MAC do cliente, IP do cliente, duração de cada sessão, data de início e fim de cada sessão. A1.R4 Anexo 3.odt Página 8/12

63 Utilizador 'admin' perdeu a sua password Este utilizador pode modificar a sua password no portal, mas caso se tenha esquecido da mesma fica impossibilitado de aceder ao portal. Deste modo é necessário aceder manualmente à base de dados e efectuar um update ao campo onde está a sua password, por uma nova. Utilizador temporário perdeu a sua password A estes utilizadores não lhes é permitido efectuar a alteração da sua senha, caso a percam o melhor será caducar a sua contar e criar uma nova. No entanto, caso esta função seja necessária, procede-se do seguinte modo: A1.R4 Anexo 3.odt Página 9/12

64 Página de administração de contas Descrição do funcionamento Acessível a partir de qualquer sítio na Internet, no endereço wifi.ipn.pt. A sua utilização é relativamente simples e serve apenas para tratar de utilizadores 'guest%', isto é, apenas de utilizadores temporários. Para aceder ao portal, o utilizador 'admin' tem de existir e teve de ser antes adicionado manualmente na base de dados, como descrito anteriormente. Esta área de gestão de utilizadores temporários foi necessária devido à complexidade dos passos que eram necessários para criar um utilizador manualmente, para além de que tinha de ser efectuado pela consola de SSH e manualmente na base de dados. Assim criou-se um sistema automático de criação e visualização destes utilizadores implementando apenas as funcionalidades que foram tidas em conta após uma análise e discussão daquilo que serviria completamente as necessidades requeridas pelo IPN. Dado que o sistema elaborado não é muito grande, nem complexo, apresenta-se de seguida um diagrama de casos de uso do sistema que contempla todas as suas funcionalidades: Casos de uso da página de administração. Cada estado apresentado representa uma página em que o utilizador tem as respectivas acções possíveis e na prática representa um ficheiro.php. Assim para cada um deles definese: Login: página onde o administrador introduz as suas credenciais. Estas estão guardadas como um utilizador na base de dados e são verificadas pelo PHP. Apenas é permitido o acesso ao utilizador 'admin'. Erro: apresenta uma mensagem de erro de autenticação, quando esta é inválida. A1.R4 Anexo 3.odt Página 10/12

65 Inicio: menu principal que contém links para as diversas áreas do portal. Password: serve para o utilizador 'admin' modificar a sua password. Criar: para criar um novo utilizador temporário, com duração variável em horas. Possui um campo para opcionalmente se introduzir uma descrição do utilizador, para possível identificação do mesmo. Depois de criado com sucesso, mostra o seu nome e password e permite abrir um ficheiro pdf com as credenciais do utilizador temporário e a sua descrição caso exista. Histórico: permite visualizar todos os utilizadores temporários que actualmente já não são válidos porque expirou o seu tempo de sessão ou porque foi banido. Acesso: mostra informação relativamente ao acesso por um determinado convidado. Mostra para cada sessão iniciada na rede, o seu endereço MAC, o IP interno atribuído, a duração da sessão, a data de inicio e de fim de cada sessão. Actuais: visualizam-se todos os utilizadores ainda válidos e também os que poderão estar em uso nesse momento. A cada um desses utilizadores é possível modificar a sua descrição e também pode-se banir o utilizador do sistema. Mesmo que ele já tenha efectuado login, assim que é caducado, é automaticamente desligado do sistema, ficando sem acesso à rede de imediato. Remover: depois de confirmar a remoção do utilizador, actualiza a base de dados, definindo o tempo limite a zero. Caso se encontre dentro no sistema é banido de imediato. Imprimir: esta funcionalidade foi construída usando o FPDF para o PHP juntamente com o FPDI. Basicamente abre-se um ficheiro 'template.pdf' existente, e a esse ficheiro apenas se insere a duração da conta (em dias e horas), a sua identificação, a descrição do convidado, a data de criação do ficheiro e finalmente as credenciais de acesso (utilizador/password). Depois de gerado o ficheiro, este pode-se guardar no disco ou imprimir para entregar a um convidado. O template tem o seguinte aspecto: - Template.pdf o que permite imprimir e dobrar, protegendo devidamente o nome de utilizador e a password. A1.R4 Anexo 3.odt Página 11/12

66 Uma vez que este está página ficou disponível num sitio público, wifi.ipn.pt, foi importante definir algum nível de segurança para além de redireccionar para HTTPS. Assim o login inicial encontra-se protegido contra ataques de injecção de código SQL, com uso a uma função do PHP que faz o parse das Strings inseridas para um modo seguro, reconhecendo por exemplo o uso de plicas e aspas. Também após login, todo o restante site está protegido com uma variável de sessão que só é activada após login com sucesso e todas as restantes páginas PHP só executam, caso esta tenha sido definida. Configuração dos acessos As definições de acesso à base de dados pelo portal e o acesso ao servidor freeradius (localmente) estão definidas no ficheiro config.php, que contém variáveis globais com estas informações. Para além desta informação, possui também a variável com o número máximo de linhas a apresentar por tabela de utilizadores. O ficheiro é apresentado de seguida: /var/www/localhost/htdocs/config.php <?php... /* Dados para a ligação à Base de Dados MySQL */ $DB_USER = "root"; $DB_PASS = "<password-do-mysql>"; $DB = "radius"; $SERVER = "localhost"; $RADIUS = " "; $COA = <porto-do-freeradius>; $RAD_SECRET = "<password-do-freeradius"; $PAGES = 17;?> A1.R4 Anexo 3.odt Página 12/12

67 A2.R1 Anexo 4 Título: Especificação de uma solução open-source para partilha de impressoras e contabilização de impressões Contacto: André Ribeiro Estagiário ajoao@ipn.pt Controlo de versões Ref. Data Alterações Responsável Documento inicial, resultado final das tarefa T1 da Actividade Revisão geral, detalhes do PyKota e descrição do protocolo IPP Revisão com objectivo de inserir o documento num anexo do relatório de estágio final. Alguma informação interna do IPN foi omitida, assim como IP's, gamas de rede, etc. André Ribeiro André Ribeiro André Ribeiro

68 Descrição Este documento tem como objectivo descrever um estudo de soluções de software opensource para a gestão e manutenção de um servidor de impressoras partilhadas, com suporte à contabilização e registo permanente do número de impressões realizadas por cada utilizador da rede informática do IPN. Como é habitual, não se consideraram soluções comerciais. Descreve-se então os gestores de impressoras encontrados, seguido das ferramentas que dão suporte à contabilização de impressões. Gestores de impressoras partilhadas Um programa de gestão de impressoras partilhadas serve basicamente para gerir todos os pedidos de impressões no sistema em que está instalado para as impressoras que controla, partilhando também essas impressoras na rede. Os que existem em licença GNU GPL para sistemas Unix e que se usam mais em larga escala são o Commom Unix Printing System (CUPS) [1] e o LPRng [2] (extensão do Line Printer Remote protocol (LPR) e do Line Printer Deamon protocol (LPD)) pelo que serão os sistemas analisados de seguida. LPRng Sistema que faz a gestão de impressões no sistema e que para além de implementar directamente o LPR e o LDP, traz mais funcionalidades, assim como: não ocupa muitos recursos (não necessita de base de dados); inclui vários programas de linha de comandos; redirecciona dinamicamente as filas de impressão; suspensão automática de trabalhos; regista detalhadamente as operações efectuadas; várias impressoras podem fazer parte da mesma fila de impressão; os programas cliente não necessitam de super user id (root); várias funcionalidades de segurança; mecanismos de permissões e autenticação; etc. Possui uma ferramenta de interface gráfica que se chama LPRng Tool, para monitorização e configuração do LPRng. Serve para verificar detalhadamente as filas de impressão e estado das impressoras, configurar o ficheiro /etc/printcap (configura manualmente impressoras do sistema, como cliente, servidor ou ambos) e configuração do filtro IFHP e suas opções. Isto porque os protocolos que implementa (LPR e LPD), apenas possibilitam as funcionalidades básicas de impressão, assim como imprimir texto simples a partir de certos comandos. Para usufruir de operações mais sofisticadas de impressão é necessário implementar um filtro de impressão. Irá ser analisado de seguida um filtro que é totalmente compatível com o LPRng. O LPRng implementa directamente a especificação da RFC1179 (LPD). A2.R1 Anexo 4.odt Página 2/6

69 É possível configurar impressoras pelos seguintes métodos: localmente (porta série, paralela, etc), por Spool Queues (filas LPD), por Sockets (IP:porto, ou também conhecido por JetDirect) ou por Samba. Principais comandos implementados no LPRng: lpr - gestor de trabalhos de impressão; lpq - monitorização de estado; lprm - cancela trabalhos de impressão; lpc - administrador de trabalhos; Filtro IFHP Um filtro de impressões serve para converter os dados dos ficheiros a imprimir para um formato que a impressora entenda, fazendo assim a transferência desses dados para a impressora e efectua alguma verificação de problemas. O LPRng usa o filtro IFHP e este pode ser configurado para o tipo de papel a imprimir, o posicionamento, as posições das margens, a qualidade impressão, etc. Este filtro pode converter qualquer ficheiro a imprimir para os formatos PS (Postscript), PCL 5, PJL (Printer Job Language) ou texto simples. Estes formatos são suportados pela grande maioria dos fabricantes de impressoras. CUPS O CUPS é o sistema de impressão mais usado hoje em dia em sistemas Unix e é mais recente que o LPRng. O seu sucesso deve-se em parte à sua facilidade de utilização e configuração, mas também porque implementa directamente os protocolos de impressão mais recentes, entre os quais o Internet Printing Protocol (IPP), que foi desenvolvido com o objectivo de colmatar algumas deficiências do antigo LPD. Para além do IPP, o CUPS também suporta o LPD, Samba e AppSocket (JetDirect). Estes protocolos definem o modo como os documentos a imprimir são enviados pela rede. O CUPS é usado tanto como gestor de impressoras em sistemas UNIX ou como gestor de impressoras em rede, uma vez que permite a sua partilha para os utilizadores da rede local. Internet Printing Protocol As maiores vantagens do protocolo IPP são: - pode ser gerido num servidor HTTP; - capacidade de saber as opções de impressão que as impressoras suportam; - controlo de acesso, de trabalhos de impressão e comandos de administração; - trabalha sobre HTTP: transporte simples e a partir de qualquer ponto da rede; - suporte de encriptação sobre SSL; - a maioria dos sistemas operativos actuais suportam o IPP. A2.R1 Anexo 4.odt Página 3/6

70 As vantagens do CUPS passam ainda por este usar uma interface Web de administração, para além de ser possível configurar tudo através de linha de comandos e ficheiros de configuração. Para instalar as impressoras usa ficheiros PPD (Postscript Printer Description) que são controladores (drivers) que descrevem todas as funcionalidades e características da cada impressora, em formato Postscript. Assim, os ficheiros.ppd possuem também código Postscript (comandos) usados para invocar trabalhos de impressão para essa impressora e são escritos em texto simples. Para as impressoras que não suportam directamente Postscript (PPD), o CUPS usa um repositório de controladores existentes no foomatic [9] que possui uma base de dados com vários tipos de controladores de código aberto, pelo que é recomendado instalar a mais recente versão desta ferramenta de, modo a obter versões mais recentes e normalizadas dos controladores das impressoras. Soluções de contadores/quotas de impressão Mais uma vez, a solução pretendida pretende-se que seja open-source e que corra no Sistema Operativo Linux. Antes de mais foi necessário instalar o Gentoo Linux numa máquina existente no IPNlis, de modo a poder testar as soluções encontradas e posterior implementação do sistema. Descartaram-se à partida todas as soluções comerciais e não são apresentadas, pois não se justificam, apesar de existirem muitas no mercado. As soluções open-source encontradas são descritas de seguida: Funcionalidade PyKota PrintBill Printquota IBQuota Linguagem de programação Python Perl + C C Bash + PHP Uso de recursos Baixo Pode ser alto se usar contador de tinta Baixo Suporte comercial Sim Sim Sim Não Release final Sim Sim Não Sim Interface Web Armazenamento centralizado (BD) Sistemas de impressão suportados Cotas de utilizadores por impressora Contagem de tinta Base de dados Requisitos Scripts CGI com estatísticas de utilização Sim, incluindo relatórios gráficos Não Baixo Sim Sim Não Sim Sim CUPS, LPRng CUPS (poucas funcionalidades), LPRng LPRng CUPS Sim Sim Sim Não Sim (com o pkpgcounter) PostgreSQL, MySQL, LDAP Python, modulo Python Sim Não Não Ficheiros de texto Perl, modulo temp do Perl, LPRng, Postgre, MySQL, ficheiros de texto LPRng, filtro IFHP, Postgresql ou MySQL CUPS, Apache, PHP, MySQL, A2.R1 Anexo 4.odt Página 4/6

71 mxdatetime, Postgresql ou MySQL, CUPS ou LPRng. Recomendados: GhostScript, Net- SNMP, netatalk, Apache. GhostScript, GhostScript fonts, Libpng Recomendados: Apache, Magicfilter, Samba, GnuPlot MySQL (recomendado), biblioteca lpopt, parsecfg (incluído), GhostScript Samba (recomendado) Documentação DocBook (sgml posível gerar PDF e HTML), Wiki, lista de , FAQ FAQ, HowTo e ficheiros de texto Ficheiros de texto FAQ, ficheiros de texto, lista de E- Mail Observações Faz a contagem de páginas por cada impressora, embora estas necessitem de ser adicionadas manualmente à base de dados do PyKota, assim como os utilizadores que se vão adicionando. Este processo pode ser simplificado com o uso de comandos que esta solução traz em que automatiza essas tarefas. É possível a cada utilizador verificar o seu total de impressões e ao administrador verificar o histórico de todas as impressões realizadas. Pode-se também definir um custo de impressão. Pode apenas contar as páginas impressas, ficando menos consumidor de recursos. Não tem suporte para BD's o que leva a uma gestão de utilizadores pouco eficaz. A compatibilidade com o CUPS está numa fase inicial e tem poucas funcionalidades. Impossibilidade de se retirar quotas, isto é, tem-se que definir sempre um limite máximo de impressões para cada utilizador ou grupo de utilizadores. Sem desenvolvimentos desde de finais de Criado com o objectivo de estabelecer quotas de impressão por cada utilizador. Regista grupos, utilizadores, impressoras e politicas de impressão. Avisa o utilizador por caso este fique sem quota e regista acções na BD. Tabela 1 Comparação das soluções de contagem de impressões; baseado no comparativo [6] e actualizado após análise de algumas das ferramentas. Conclusões Após este comparativo para soluções de estabelecimento de quotas e contabilização de impressões por utilizadores, verificou-se que a algumas delas ainda estão em fase de desenvolvimento (com funcionalidades em lista todo) ou acabaram por ser abandonadas, pois já há alguns anos que não são actualizadas. Isto, apesar de fornecerem funcionalidades básicas que poderiam ser úteis para o que se pretende implementar. No entanto aquele que se apresenta mais completo e funcional com o gestor de impressão pretendido é o PyKota. As maiores vantagens que apresenta sobre as outras soluções, para além de responder aos requisitos que se pretendem, são as seguintes: funciona em conjunto com o CUPS, suporte de registo em base de dados, consulta de impressões por interface Web, possibilidade de efectuar A2.R1 Anexo 4.odt Página 5/6

72 a contagem de área de tinta impressa. O uso do IPP para configurar e enviar os trabalhos de impressão revelou-se bastante eficaz, pois este é bastante simples e seguro (pode trabalhar sobre HTTP/S), sendo que a solução escolhida, CUPS com PyKota, suporta de raíz este protocolo. Foram realizados alguns testes com sucesso usando o CUPS como servidor e um cliente em Windows XP. No entanto, ficou ainda por testar o sistema de contabilização PyKota, assim como a parte de autenticação destes, apesar de ser ter verificado que seria esta a solução a implementar. Referências A2.R1 Anexo 4.odt Página 6/6

73 A2.R3 Anexo 5 Título: Procedimentos e configurações de manutenção do servidor de impressoras Contacto: André Ribeiro Estagiário ajoao@ipn.pt Controlo de Versões: Ref.: Data Alterações Responsável Documento inicial. André Ribeiro Adição da configuração automática do envio de André Ribeiro para a equipa de suporte e para os utilizadores das impressoras Adição da secção 'utilizadores não conseguem imprimir'. Revisão com objectivo de inserir o documento num anexo do relatório de estágio final. Alguma informação interna do IPN foi omitida, assim como IP's, gamas de rede, etc. André Ribeiro

74 ÍNDICE OBJECTIVOS...3 SERVIÇOS NA MÁQUINA 'PRINT'...3 CONFIGURAÇÕES DE REDE...3 FIREWALL - IPTABLES...3 CUPS...4 PYKOTA...4 SAMBA E KERBEROS...4 'S PERIÓDICOS...5 TAREFAS COMUNS...5 VERIFICAR IMPRESSÕES DOS UTILIZADORES...5 ADICIONAR/REMOVER IMPRESSORAS...6 VERIFICAR EXISTÊNCIA DE UTILIZADOR...7 ACEDER À PÁGINA DE RELATÓRIOS...7 ALTERAR PASSWORD DO UTILIZADOR DE ACESSO À PÁGINA DE RELATÓRIOS...7 OS UTILIZADORES NÃO CONSEGUEM IMPRIMIR...8 REFERÊNCIAS...8 A2.R3 Anexo 5.odt Página 2/8

75 Objectivos Este documento tem como objectivo principal dar suporte na configuração e execução de tarefas comuns no servidor de impressões do IPN. Deverá então ser legível e perceptível sem dificuldades por qualquer elemento da USIC, de modo a permitir uma rápida execução de qualquer tarefa que seja necessária. Serviços na máquina 'print' Os principais serviços que ai correm são os seguintes: Apache2, CUPS, Iptables (script de regras /etc/init.d/firewall.iptables), MySQL, Samba, SSH, Syslog-ng e Vixie-cron, para além da interface de ligação à rede Os serviços encontram-se prontos a serem carregados ao arranque, pois no caso de um reboot inesperado o tempo de recuperação do estado funcional seja o menor possível. Para isso configurou-se os serviços com o comando 'rc-update'. Configurações de rede A máquina encontra-se actualmente na rede de servidores, da gama <rede-servidores> e tem configurado manualmente o IP <IP-print-server> na interface ethx. Apesar de possuir uma outra placa de rede (ethy), esta não está configurada por não ser necessária. Para a sua configuração automática ao arranque, temos o seguinte ficheiro: /etc/conf.d/net config_ethy=( " " ) dhcp_ethy="nodns nontp nonis" config_ethx=( "<IP-print-server> netmask <mascara-print-server>" ) routes_ethx=( "default via <gateway-interna-servidores>" ) Para além disto, é importante ter em conta que a máquina responde internamente pelos nomes 'print' e 'print.ipn.pt', isto porque foi adicionada nos servidores de DNS internos do IPN. /etc/resolv.conf search IPN.PT domain IPN.PT nameserver <DNS-interno-1> nameserver <DNS-interno-2> Firewall - Iptables A Firewall em uso, serve apenas para proteger a máquina internamente, uma vez que esta só é acessível na rede interna do IPN. Deste modo apenas se permite tráfego à chega e à saída da máquina, uma vez que o tráfego em passagem é da responsabilidade da aplicação de gestão de impressoras (CUPS). Então, à entrada temos: SSH, HTTP, HTTP/S, IPP, SNMP e ICMP. À saída da máquina temos: SSH, SMTP, DNS, HTTP, Kerberos, SNMP, Kerberosadmin, IPP, Rsync, JetDirect (TCP 9100) e ICMP. A2.R3 Anexo 5.odt Página 3/8

76 O script de configuração e inicialização ao arranque encontra-se em: /etc/init.d/firewall.iptables. CUPS O CUPS é a aplicação principal do servidor de impressões. Está configurado para aceitar ligações seguras e autenticadas pelos utilizadores. Apenas está a permitir acesso de configuração a um endereço em específico (para administração). O seu principal ficheiro de configuração é o seguinte: /etc/cups/cups.conf. O endereço para se aceder à sua página Web de administração é: print.ipn.pt:631. Importante também é o ficheiro onde se configuram as impressoras, que contêm indicações da sua localização (IP) e modo de acesso, por IPP ou por Socket: /etc/cups/printers.conf. Este é modificado automaticamente quando é feita alguma alteração nas configurações das impressoras ou quando se adiciona ou remove alguma do sistema. PyKota Este é o programa que contabiliza o número de impressões realizadas por cada utilizador e funciona como um backend do CUPS, isto é, depois de instalado e configurado, as impressoras a configurar no CUPS usam programa para contabilizar as impressões e registar na base de dados MySQL. Ao instalar o PyKota no Linux Gentoo, verificou-se que existia um bug, no repositório de software Portage, e a sua instalação não era a mais indicada, pelo que se teve de consultar a sua resolução online [1]. A sua instalação e configuração foi realizada segundo a documentação oficial, disponível na pasta '/root/backups/pykota-docs' em HTML. Também é necessário criar no sistema o utilizador 'pykota', de modo a ser este a executar o 'backend' do CUPS e colocar os ficheiros de configuração na home deste utilizador. Os seus ficheiros de configuração encontram-se em /home/pykota/pykotadmin.conf e /home/pykota/pykota.conf. Samba e Kerberos A autenticação dos utilizadores no CUPS é feita remotamente com o PAM (Pluggable Authentication Modules), daí a necessidade de obter os utilizadores da máquina kerberos.ipn.pt autenticados localmente. Para tal usou-se o serviço winbind do Samba. A máquina foi adicionada ao domínio IPN.PT e configurada com o cliente Kerberos (krb5-mit). A instalação e configuração deste serviço foi baseada numa Wiki do Gentoo [2]. Os principais ficheiros de configuração encontram-se em: /etc/krb5.conf e /etc/samba/smb.conf. A2.R3 Anexo 5.odt Página 4/8

77 's periódicos Foram criados dois scripts em PHP que se encontram em /root/scripts/, em que o primeiro (mail-suporte.php) envia um à equipa de suporte com o relatório completo do número de impressões que cada utilizador efectuou em cada impressora. O segundo (mail-users.php), envia um individual a cada utilizador que tenha usado as impressoras, apenas com o seu número de cópias e o seu respectivo histórico. Após estes scripts serem executados, procede-se à reinicialização dos contadores, com o comando: 'edpykota --reset', que coloca a zero o contador actual de todos os utilizadores em todas as impressoras, mas mantêm o seu histórico inalterado. A automatização deste processo e consequente periodicidade é feita com o Cron, e de momento está programado para executar mensalmente o script bash que se encontra em '/etc/ cron.monthly/pykota.sh', que por sua vez executa os scripts e no final reinicia os contadores. Para programar o dia do mês, a semana ou a hora a que deve ser executado, basta editar o ficheiro /etc/crontab, e caso se mude de período é necessário mover o pykota.sh para o local certo (hourly, daily, weekly ou monthly). No final, reiniciar o serviço com o comando: '/etc/init.d/vixie-cron restart'. Para modificar qualquer informação relativa aos 's enviados, deve-se editar o ficheiro config.php, que contém as principais configurações usadas e informações como o assunto, o utilizador que envia o , o endereço para o qual se envia o relatório completo, etc. Para ter suporte de envio de 's em PHP a partir da máquina 'print', foi necessário recorrer à ferramenta open-source PHPMailer [1], que liga internamente ao servidor 'mail.ipn.pt'. Tarefas comuns Nesta secção descrevem-se as tarefas que esporadicamente, podem ser necessárias para a manutenção do servidor de impressões. Verificar impressões dos utilizadores Para tal existem dois modos de aceder aos registos da base de dados MySQL de modo a consultar o número de impressões realizadas por cada utilizador no IPN: por linha de comandos na máquina 'print' ou através do endereço Web, disponível na rede interna do IPN em print.ipn.pt (ou apenas print). Neste endereço é necessário colocar o utilizador 'usic' com a password partilhada e de conhecimento da equipa da USIC. Este acesso foi configurado com o serviço do Apache htaccess e os seus ficheiros de configuração e de passwords encontram-se na pasta /var/www/localhost/cgi-bin/. Para apresentar esta página usou-se um script 'printquota.cgi' que vinha com o PyKota. Também é possível executar os scripts para receber automaticamente um com estas informações, disponíveis na pasta '/root/script/'. No entanto, estes serão executados periodicamente pelo Cron. A2.R3 Anexo 5.odt Página 5/8

78 Para consultar os dados na linha de comandos, basta executar 'repykota' ou 'repykota -P <nome-impressora>' para uma impressora em específico. Este é um comando do PyKota que apresenta a quantidade de impressões por cada utilizador existente na base de dados MySQL. Adicionar/Remover Impressoras Para tal é necessário ter a opção de Browsing activa no CUPS, que está desactivada por motivos de segurança. Depois disso, procede-se normalmente a adicionar ou remover uma A2.R3 Anexo 5.odt Página 6/8

79 impressora no CUPS de modo habitual, na sua página Web de configuração. No final adicionase ou remove-se da base de dados do PyKota recorrendo a um comando que automatiza este processo. Também é necessário verificar com que método de contagem, no PyKota, em que a impressora trabalha correctamente, isto porque depende da própria impressora. Por fim, recomenda-se que se volte a desactivar o Browsing no CUPS. Verificar existência de utilizador Pode-se verificar se existe no servidor de autenticação 'kerberos.ipn.pt', ou se já existe na base de dados do Pykota, isto é, se já foi inserido como utilizador do sistema de impressões. Aceder à página de relatórios Alterar password do utilizador de acesso à página de relatórios A2.R3 Anexo 5.odt Página 7/8

80 Os utilizadores não conseguem imprimir Durante os testes efectuados ao sistema implementado verificaram-se vários tipos de problemas, que por vezes ocorrem não pelo incumprimento de serviços pelo servidor, mas por motivos que se verificam regularmente e impedem o normal funcionamento do sistema. Então, o que se pretende nesta secção é dar suporte aos problemas mais comuns, apresentando as resoluções encontradas para tal. Problema A impressora não possui papel. Encravou o papel à saída. Não há tonner ou tinteiro. Não existe conectividade. Não é possível cancelar o trabalho de impressão. Resolução 1. Ir até à impressora e verificar se tem papel. Caso não tenha papel na gaveta pré-definida, mas tenha na outra, o cliente tem de configurar no controlador a escolha automática da gaveta a usar. 2. Se após colocar papel, o trabalho não for impresso, verificar os logs do sistema com o comando: tail- f /var/log/messages Caso surjam mensagens de erro do PyKota, foi porque está à muito tempo com o problema. 3. Caso se verifique o passo anterior, reiniciar o CUPS: /etc/init.d/cupsd restart 1. Ir até à impressora para remover o papel encravado. Proceder de uma forma semelhante à resolução anterior. 1. Ir até à impressora e substituir o tonner/tinteiro. Proceder de uma forma semelhante da primeira resolução. 1. No cliente, verificar conectividade para o print-server: ping print.ipn.pt. No caso de estar ligado com o openvpn em Linux, verificar se o nome 'print.ipn.pt' adicionado no ficheiro /etc/hosts. 2. No print-server verificar conectividade para as impressoras, com ping's para os seus IP's ou na interface Web do CUPS, no estado das impressoras. 1. O CUPS diz que a impressora está 'busy' e não dá para cancelar o trabalho de impressão. Na linha de comandos fazer 'ps aux' e ver qual é o processo do utilizador pykota que está a executar esse trabalho. 2. Terminar o processo manualmente: kill -9 <pid-processo> 3. Reiniciar o CUPS: /etc/init.d/cupsd restart Utilizador não imprime porque o CUPS não consegue autenticar. Utilizador não é válido. 1. Verificar os logs do sistema: tail- f /var/log/messages 2. Caso haja a mensagem de 'clock skew' foi porque o relógio local está muito diferente do servidor de autenticação. Proceder com o seguinte comando: ntpdate kerberos.ipn.pt 1. Na linha de comandos do print-server: kinit <user>@ipn.pt 2. klist 3. kdestroy Referências [1] - [2] /04/2008 [3] - A2.R3 Anexo 5.odt Página 8/8

81 A2.R3 Anexo 6 Título: Screenshot's da página Web de suporte à configuração das impressoras nos clientes em Windows XP e Linux Contacto: André Ribeiro Estagiário ajoao@ipn.pt Controlo de Versões: Ref.: Data Alterações Responsável Documento inicial, criado a partir da impressão do conteúdo principal da página Web para pdf. André Ribeiro

82 Documentos de Apoio aos Utilizadores do IPN 1 of :00 Instalação das Impressoras partilhadas do IPN Windows XP 1. O primeiro passo será dirigir-se ao botão de "Start" ("Iniciar"), escolhendo a opção "Settings" ("Definições"), seguido de clique em "Printers and Faxes" ("Impressoras e Faxes"): 2. Agora clique em "Add Printer" ("Adiccionar Impressora"), seguido de "Next" ("Seguinte"): 3. Seleccionar o tipo de impressora "A network printer" ("Impressora em rede"):

83 Documentos de Apoio aos Utilizadores do IPN 2 of :00 4. Localizar a impressora pretendida no URL certo (terá de ter conectividade na rede interna do IPN após este momento): URLs para cada impressora: HP OkiC HP1125C Inserir as credencias do utilizador do IPN: 6. Seleccione o driver certo para a impressora:

84 Documentos de Apoio aos Utilizadores do IPN 3 of :00 Pode descarregar os seguintes drivers: HP4350 Windows 2000/XP/2003/Vista OkiC5400 Windows 2000/XP HP1125C Escolher HP -> HP DeskJet 1125C 7. Clicar em "Next" ("Seguinte") e "Finish" ("Terminar"): 8. Neste momento deverá ter a impressora instalada com sucesso: Notas: - o sistema ainda não foi testado para o sistema operativo Windows Vista. - para imprimir em "Duplex" deverá activar esta opção nas propriedades avançadas da impressora. - na HP4350, o driver por defeito não instala a 3ª unidade de papel e apenas usa a 2ª, pelo que deverá activa-lo também nas propriedades avançadas.

85 Documentos de Apoio aos Utilizadores do IPN 1 of :08 Instalação das Impressoras partilhadas do IPN Linux (CUPS) O CUPS é o gestor de impressoras mais usado actualmente em sistemas operativos Unix. Assume-se que o utilizador já o tenha instalado no seu computador e que está a correr. Deverá também ter previlégios de administrador "root". Para submeter os trabalhos para as impressoras, é necessário criar primeiro uma ligação para o protocolo seguro (HTTPS), que o CUPS não traz por defeito. Depois basta adicionar a impressora através da sua interface Web. Para tal executar os seguintes passos: 1. Mudar para a seguinte directoria (dependendo da distribuíção): cd /usr/libexec/cups/backend/ (Gentoo) cd /usr/lib/cups/backend/ (Ubuntu) 2. ln -s ipp https 3. /etc/init.d/cupsd restart (Gentoo) /etc/init.d/cupsys restart (Ubuntu) 4. Com um navegador Web abrir: 5. Clicar em "Add Printer" ou "Administration" e "Add Printer". Normalmente será solicitado ao utilizador as credênciais de Administrador (root) da máquina local.

86 Documentos de Apoio aos Utilizadores do IPN 2 of :08 6. Introduzir um nome para a impressora (obrigatório), localização e descrição opcionais: 6. Seleccionar "Internet Printing Protocol (https)": 7. Inserir o URL definido da seguinte forma: Em que cada nome da impressora corresponde: HP Laser a Preto/Branco OkiC Laser a Cores HP1125C - Jacto de Tinta A3

87 Documentos de Apoio aos Utilizadores do IPN 3 of :08 8. Escolher o devido driver para a impressora: Pode descarregar os seguintes drivers: HP4350 HP4350.ppd Mac OS X OkiC5400 OkiC5400.ppd Mac OS X HP1125C HP1125C.ppd Por questões de segurança recomenda-se que não instale as impressoras em máquinas acessíveis por várias pessoas. Ao inserir as credênciais, estas ficam visíveis no ecran, pelo que se recomenda algum cuidado. NOTA: Os utilizadores da OpenVPN, tanto fora do IPN como na rede Wireless, recebem por vezes os DNS externos, pelo que ficam sem conectividade ao servidor "print.ipn.pt". Para resolver basta, no ficheiro /etc/hosts acrescentar a seguinte linha: print.ipn.pt

88 A3.R1 Anexo 7 Título: Análise de soluções open-source para contabilização de tráfego IP Contacto: André Ribeiro Estagiário ajoao@ipn.pt Controlo de Versões: Ref.: Data Alterações Responsável Documento inicial. André Ribeiro Revisão com objectivo de inserir o documento num anexo do relatório de estágio final. Alguma informação interna do IPN foi omitida, assim como IP's, gamas de rede, etc. André Ribeiro

89 Descrição Neste documento encontra-se a análise detalhada a cada ferramenta de contabilização de tráfego open-source encontrada após várias pesquisas. O objectivo principal destas é contabilizar o tráfego apenas, de e para o exterior da rede do IPN. A análise desse tráfego deverá ser feita por VLAN, que identifica cada laboratório, e opcionalmente por cada utilizador ou máquina. Estes dados deverão ser registados periodicamente, de modo a poderem ser consultados mais tarde. NTop Desenhado, à semelhança do 'Top' em Linux (para verificação do estado do sistema, CPU e memória), o NTop serve para monitorização do estado da rede. É um monitor híbrido de layer 2 e 3, isto é, captura tráfego a nível da ligação lógica (MAC) e/ou de rede (IP:porto). A captura de tráfego é feita com o auxilio do libpcap (mesmo que tcpdump) e pode trabalhar em modo promíscuo, isto é, com a opção de verificar todo o tráfego numa interface, mesmo que esse tráfego não seja destinado para essa interface. Incorpora um servidor Web para visualizar os resultados e é bastante completo e agradável em termos de apresentação. É este o modo que usa para visualizar a informação obtida e revelase bastante eficaz, pois a informação geralmente é muito completa e bem apresentada. Os seus principais menus de visualização são: - Global Traffic Statistics: apresenta todo o tráfego à entrada e à saída da interface de escuta; tamanho dos pacotes; TTL dos pacotes; débito bruto actual, de pico e médio dos últimos 5min; percentagem global dos protocolos usados (TCP, UDP ou ICMP); percentagem global dos portos predefinidos para verificação (aplicação: HTTP, Mail, DNS, etc.); lista de todos os portos mais usados globalmente no último minuto. - Host Information: lista as máquinas que mais largura de banda consumiram nas últimas horas, tanto a receber como a enviar. - Network Traffic: lista todo o tráfego de todas as máquinas que captura, com a soma de todo o tráfego em quantidade e separadamente por serviço de aplicação usado, predefinido pelos portos; permite ordenar por IP (ou nome, caso o resolva por DNS) de cada máquina, pelos dados totais ou pela aplicação mais usada; pode agrupar pelos seguintes grupos: - dados recebidos pelas máquinas do IPN - downloads; - dados enviados pelas máquinas do IPN - uploads; - dados recebidos da rede do IPN pelas máquinas externas; - dados enviados para a rede do IPN pelas máquinas externas. - Throughput: lista todas as máquinas, com o seu débito actual, médio e de pico; possibilidade de ordenar por cada um destes valores, ou por IP (ou nome, caso o resolva por DNS). A3.R1 Anexo 7.odt Página 2/6

90 - IP Protocol Distribution: à semelhança do 'Global Traffic Statistics', mas apresenta a distribuição dos protocolos usados, agrupados por tráfego local, remoto para local, remoto e local para remoto. O NTop oferece muitas funcionalidades para além destas. Permite por exemplo, verificar os detalhes do tráfego enviado, recebido, hosts remotos contactados e portos usados por cada host que têm no seu registo. Uma das suas desvantagem é, sem dúvida a grande utilização de CPU e de memória, que no entanto depende da carga de tráfego a analisar. Mesmo assim, a sua carga de processamento pode ser minimizada ao desactivar algumas funcionalidades, dependendo claro, do cenário a implementar e dos requisitos para qual se pretende implementar. Também a possibilidade de registar em disco a informação que adquire não é a mais simpática, é apenas efectuada por alguns plugins que vem com o programa e guarda os dados no formato RRD (Round Robin Databases), escolhendo o tipo de informação que se pretende guardar e o nível de detalhe desta. O problema deste formato é a forma de ler e visualizar os ficheiros.rrd, que nem sempre é fácil de trabalhar. Também pode registar do mesmo modo, ligações NetFlow e sflow (proprietárias da Cisco). Após alguns testes com esta ferramenta, verificou-se que apresenta informação muito útil para detectar anomalias espontâneas na rede, desde clientes com largura de banda a mais até utilização de certo tipo de protocolos a nível de aplicação algo suspeitos. No entanto, se o programa que corre 24h/dia mantém em memoria os dados para apresentação e devido ao seu grande crescimento, a informação antiga (histórico) é descartada ao fim de 12 a 24 horas. Também ao efectuar 'restart' à aplicação, os dados são perdidos. IPAC-NG Contador de tráfego IP que trabalha sobre o iptables ou ipchains em Linux. Assim, para a análise de tráfego basta definir as regras de acesso onde se pretende contabilizar o tráfego, logo é fácil deduzir que apenas trabalha em layer 3. Lê directamente os contadores do Kernel do sistema e guarda-os em ficheiro ou numa base de dados (gdbm ou MySQL) para posterior análise. A leitura dos dados no Kernel deve ser efectuada com uma certa frequência, pelo que se recomenda o uso do Cron para tal, a fim de adoptar uma frequência de actualização dos dados à medida. O facto de estar dependente de ler apenas os pacotes que passam pelo Kernel (iptables ou ipchains), faz com que não seja possível efectuar leitura em modo promíscuo. Isto porque o Kernel está configurado a capturar pacotes que são direccionados para a própria máquina, ou seja com o endereço MAC (layer 2) de destino à interface física da máquina. A3.R1 Anexo 7.odt Página 3/6

91 Possibilita a criação de gráficos em ficheiros de imagem.png a partir da linha de comandos e também a consulta dos dados registados em modo de texto. Apesar de não ser muito prático na sua visualização, é bastante eficiente ao realizar aquilo para que foi construído, que é contabilizar tráfego, em quantidade (bytes) e também em número de pacotes. A definição daquilo que se pretende medir (de certas VLAN's, que protocolos, ou individualmente por IP's, etc.) é sempre efectuada segundo a adição de regras para cada caso, o que torna a sua implementação mais complexa e difícil de actualizar. Layer-7 Filter Como o próprio nome indica, esta ferramenta faz a classificação de tráfego em layer 7, ou seja a nível de aplicação. Construído para trabalhar inicialmente no Kernel do Linux, trabalha exclusivamente com o iptables/netfilter e é um módulo de 'match' para este classificar os protocolos do tráfego da máquina onde está a correr. A sua existência deve-se ao facto de a análise em layer 3 não dar totais garantias dos protocolos que estão a ser usados. Por exemplo, os casos conhecidos de mais difícil classificação são as aplicações Peer-2-Peer (P2P) que usam qualquer tipo de porto para comunicar, ficando assim a sua identificação em layer 3 comprometida. Devido a esta situação, o Layer-7 Filter surge numa tentativa de superar esta situação. Analisa o conteúdo dos pacotes através da comparação de expressões regulares nos cabeçalhos dos protocolos da camada de aplicação (SSH, HTTP, Torrent, etc.), que se sabe que estas usam. No entanto, podem surgir casos em que as próprias aplicações podem 'dar a volta' a este sistema de análise, usando outros campos ou até ao cifrarem o tráfego e nesse caso não é possível classifica-lo correctamente. O Layer-7 Filter faz o seu melhor nesta situação, e contêm uma lista dos protocolos que classifica, com as expressões regulares que usa. Assim essa lista, deverá ser actualizada regularmente, de modo a essa classificação estar sempre mais próxima possível da realidade. Do mesmo modo que o IPAC, o Layer-7 Filter trabalha apenas com o iptables/netfilter, que por sua vez tem de estar compilado no Kernel, e este apenas processa tráfego que é direccionado para máquina, não sendo possível monitorizar tráfego em modo promíscuo. Importante também, será a capacidade de processamento necessária para correr esta aplicação, pois certamente é bem maior que uma análise em layer 3. O seu desempenho é anunciado como sendo bom para redes de pequenas e médias dimensões, mesmo a correr em estações de trabalho de baixo ou médio desempenho. Actualmente está a ser desenvolvida uma versão que trabalha no espaço de utilizador normal, que procura ser mais simples de instalar, pois a versão estudada, necessita de um patch no Kernel, selecção dos módulos 'conntrack' e 'layer7', seguido da recompilação deste. Também o iptables terá de ser recompilado depois de se aplicar o patch do Layer-7 Filter, de modo a este carregar os novos módulos. A3.R1 Anexo 7.odt Página 4/6

92 IPTraf Esta solução trabalha em modo consola no Linux. Tem um menu próprio e é bastante simples de se usar. Foi desenhado para monitorizar o estado de uma ou várias interfaces de rede da máquina onde está a correr e têm opção de analisar o tráfego em modo promíscuo. As suas principais funcionalidades passam por: contabilizar o tráfego em número de pacotes, quantidade de informação e débito por máquina (à entrada e à saída); distribuição por portas; adição de filtros para ver apenas o que se pretende; registo de dados apenas em ficheiros de logs; possibilidade de analisar apenas nas interfaces que se pretende. Apesar de ser bastante simples de o colocar a monitorizar tráfego na rede, apresenta algumas desvantagens principais, que o inviabilizam de o por em produção no IPN. Nomeadamente o facto de não correr como 'deamon' (em background) e a análise do tráfego é apenas em tempo real, ou seja, só é possível monitorizar quando este está a correr. Também não é desejável guardar o histórico em ficheiros de log, o que tornava a sua análise mais complexa. A verificação de tráfego por máquina é possível, mas é apresentada por endereço MAC em vez de IP, o que se torna muito difícil de se verificar porque existem muitas máquinas activas. O IPTraf é então um monitor de rede de Layer 2 e 3, simples e eficaz, mas não recomendado para redes com mais de algumas máquinas activas. PMACCT PMACCT refere-se ao nome Promiscuous Mode IP Acounting Package e é uma ferramenta de monitorização de rede para medir e contabilizar tráfego IP. Corre em Linux e outros Sistemas Operativos baseados em Unix. Usa também o libpcap para capturar tráfego e integra algumas das suas funcionalidades. Também permite capturar NetFlow e sflow. As suas principais funcionalidades são: regista informação em memoria, base de dados MySQL, PostgreSQL ou SQLite; pode exportar dados para NetFlow v5/v9 ou sflow V9; flexibilidade de agregar, filtrar, direccionar e separar dados obtidos; classificar certo tipo de tráfego não comum (ainda em desenvolvimento); possibilidade modificar filtros, rede ou backends de informação com facilidade; possibilidade de registar os dados em Round Robin (com gravação periódica e permanente de uma forma programada). Depois de os dados estarem num suporte de informação à escolha, é possível exportar os dados graficamente para um front-end mais amigo do utilizador. Existem várias possibilidades, como por exemplo o RRDTool, GNUPlot, Cacti, BWstat, pnrg, etc. O mais simples e funcional encontrado foi o BWstat, que é basicamente um portal em PHP pronto a ler dados da base de dados do PMACCT. Foi necessário criar a base de dados MySQL com o script que trazia para tal, depois foi necessário definir as redes ou IP's a mostrar os dados pretendidos no portal. Permite visualizar a informação relativamente ao ano, mês, dia e hora, caso os registos sejam efectuados no mínimo de hora em hora. A3.R1 Anexo 7.odt Página 5/6

93 Conclusões do estudo Para além das soluções aqui apresentadas, existem muitas mais (também open-source) no âmbito de analisar o estado de redes IP. Não se apresentam aqui porque verificou-se logo de início que não preenchiam os requisitos, que passam por contabilizar o tráfego em quantidade e em tipo (protocolo), por VLAN (ou gama de endereços específicos) e opcionalmente por máquina. Os sistemas analisados apresentaram-se bastante bons à excepção do IPTraf, que em comparação por exemplo com o NTop, fica bastante longe das suas funcionalidades e modos de visualização. Mesmo assim, a implementação de estas ferramentas estarão sempre dependendo do cenário que se usar para efectuar a monitorização da rede. Notar também que, a eficiência do Layer-7 Filter não está ainda testada, pois só com testes exaustivos e ao fim de um certo tempo de execução é que se podem tirar conclusões se vale a pena ou não, uma vez que apresenta um modo de análise bastante diferente de todos os outros apresentados. Referências A3.R1 Anexo 7.odt Página 6/6

94 A3.R3 Anexo 8 Título: Manual de procedimentos e configurações do servidor Traffic Monitor Contacto: André Ribeiro Estagiário ajoao@ipn.pt Controlo de Versões: Ref.: Data Alterações Responsável Documento inicial. André Ribeiro Revisão com objectivo de inserir o documento num anexo do relatório de estágio final. Alguma informação interna do IPN foi omitida, assim como IP's, gamas de rede, etc. André Ribeiro

95 ÍNDICE OBJECTIVOS...3 PRINCIPAIS CONFIGURAÇÕES...3 SERVIÇOS NA MÁQUINA 'SHAPER'...3 CONFIGURAÇÕES DE REDE...3 FIREWALL - IPTABLES...4 NTOP...4 PMACCT...5 SERVIDORES COM NAT NA FIREWALL...6 TAREFAS COMUNS...6 NTOP - CONSULTAR ESTATÍSTICAS...6 NTOP - ADICIONAR/REMOVER PROTOCOLO PARA MONITORIZAR...7 NTOP - MODIFICAR A PASSWORD DO UTILIZADOR 'ADMIN'...8 PMACCT/BWSTAT - CONSULTAR ESTATÍSTICAS...8 BWSTAT - MODIFICAR A PASSWORD DO UTILIZADOR 'ADMIN'...9 NTOP E PMACCT - ADICIONAR/REMOVER NOVA REDE LOCAL...9 A3.R3 Anexo 8.odt Página 2/9

96 Objectivos Este documento tem como objectivo principal dar suporte na configuração e execução de tarefas comuns na máquina de monitorização de tráfego do IPN, para além de ajudar a equipa de suporte técnico nos vários modos de consulta à informação registada. No inicio dos trabalhos, foi dado o nome 'shaper' à máquina usada, que na realidade é apenas monitor e não classificadora de tráfego e de prioridades, pelo que deve ser entendida como 'monitor'. A descrição da configuração dos serviços que correm na máquina, deve dar uma ideia clara daquilo que se monitoriza na rede do IPN e serve a dar suporte a qualquer modificação ou manutenção que seja necessária efectuar pela equipa da USIC no futuro. De seguida descreve-se a questão dos servidores com NAT na Firewall e os métodos passo a passo dos procedimentos mais comuns que se realizam. Principais configurações Serviços na máquina 'shaper' Os principais serviços que ai correm são os seguintes: apache2, ntop, pmacctd, iptables (script de regras /etc/init.d/firewall.iptables), MySQL, sshd, syslog-ng e vixie-cron. Os serviços encontram-se prontos a serem carregados ao arranque, pois no caso de um reboot inesperado o tempo de recuperação do estado funcional seja o menor possível. Na BIOS da máquina foi activada a opção de 'power-on', numa situação de falha de energia, ou seja, a máquina liga-se automaticamente após uma falha de energia. Configurações de rede A máquina encontra-se actualmente na rede de servidores, da gama <IP-servidores/mascara> e tem configurado manualmente o IP <IP-shaper> na interface ethx. Esta serve para conectividade à rede interna do IPN, pelo que o seu acesso é por esta. A segunda placa de rede (ethy), é a que recebe o tráfego da porta em Mirror e é de 1000Mbps, pois a ligação entre o Switch e a Firewall trabalha a este débito. Uma vez que vai receber todo o tráfego em modo promíscuo, essa interface ficou configurada sem IP. Para a sua configuração automática ao arranque, temos o seguinte ficheiro: /etc/conf.d/net config_eth0=( "<IP-servidores/mascara>" ) routes_eth0=( "default via <gateway-servidores>" ) config_eth1=( " " ) A3.R3 Anexo 8.odt Página 3/9

97 Firewall - Iptables A firewall em uso, serve apenas para proteger a máquina internamente, uma vez que esta só é acessível na rede interna do IPN. Deste modo apenas se permite tráfego à entrada e à saída da máquina, na interface ethx, que é a que tem acesso à rede. À saída da máquina permite-se: SSH, DNS, HTTP, RSync e ICMP. À entrada da máquina permite-se: SSH, HTTP, HTTP do NTop (porto TCP 3000) e ICMP. O script de configuração e inicialização ao arranque encontra-se em: /etc/init.d/firewall.iptables. NTop O NTop corre em background e para ser consultado basta ir ao endereço 'shaper.ipn.pt' (ou apenas 'shaper'), acessível apenas na rede interna do IPN. Uma vez que este, por defeito, captura todo o tráfego numa dada interface, foi necessário configura-lo de um modo mais optimizado e à medida das necessidades. Nesta configuração incluí-se o seguinte: indicação das redes que são locais; é carregado um ficheiro com a lista de protocolos (layer 3) a identificar; o filtro do libpcap que permite capturar apenas o tráfego que vai para o exterior e o que é recebido do exterior. Assim o tráfego local e o tráfego inter VLAN's fica excluído da monitorização, visto que não existe interesse nesse aspecto. O ficheiro de configuração deste serviço é o próprio script de inicialização, e encontra-se em: /etc/init.d/ntop #!/sbin/runscript # Copyright Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # Opções usadas: # --local-subnets: defines the local networks. # --disable-decoders: disables protocol decoders. # --no-mac: do not trust MAC address, promiscuous mode. # --disable-sessions: disable TCP session tracking. # --user: defines the user to run ntop. # --domain: defines the local domain. # --disable-schedyield: disables sched_yield() calls. # --protocols: defines the set of layer3 protocols to indentify. # --db-file-path: where the ntop RRD files are. # --interface: where to capture traffic. # --filter-expression: libpcap filter. # Filtro libpcap # 1º-Define-se que não se quer capturar tráfego entre as redes locais: <gama-local> e <gama-externa> # 2º-Define-se que não se quer capturar tráfego dos gateways (virtuais) que fazem NAT na Firewall do IPN, apanhando assim só o tráfego do cliente. NTOP_OPTS='<Opções usadas> + <Filtro libpcap>'... # Restante script do NTop... A3.R3 Anexo 8.odt Página 4/9

98 Os protocolos actualmente a serem filtrados, isto é, de modo ao NTop apresentar estes separadamente, estão configurados no seguinte ficheiro: /root/protocols.lst PROTOCOLO_1=portos_usados nomes_/etc/services gama_de_portos PROTOCOLO_N=portos_usados nomes_/etc/services gama_de_portos Para adicionar outros protocolos, bastar editar este ficheiro e acrescentar os portos pretendidos (considera TCP e UDP em simultâneo), consoante seja necessário, seguido de um 'restart' ao NTop, o que fará com que se perda os dados das últimas horas de execução deste. PMACCT Esta ferramenta, é um contador de tráfego em modo promíscuo, que assim como o NTop também recorre ao libpcap para realizar a captura de tráfego, na mesma interface (ethy). A sua configuração é bastante simples e define a configuração da base de dados a usar, no caso implementado a do BWstat. O filtro do libpcap, é igual ao do NTop, de modo a verificar apenas tráfego do IPN para o exterior e vice-versa. /etc/pmacctd.conf debug: false interface: ethy promisc: true daemonize: true plugin_buffer_size: 2048 plugin_pipe_size: networks_file: /root/networks.lst plugins: mysql[in], mysql[out] aggregate[in]: dst_net aggregate[out]: src_net!1º-define-se que não se quer capturar tráfego entre as redes locais: <gama-local> e <gama-externa>!2º-define-se que não se quer capturar tráfego dos gateways (virtuais) que fazem NAT na Firewall do IPN, apanhando assim só o tráfego do cliente. pcap_filter: <Filtro libpcap, igual ao do NTop> sql_db: bwstat sql_table: acct sql_table_version: 1!Actualiza a BD de 5 em 5 min sql_refresh_time: 300!Guarda permanentemente os dados de hora em hora sql_history: 1h sql_history_roundoff: mh sql_host: localhost sql_user: bwstat sql_passwd: <password-mysql> O ficheiro onde estão definas as redes locais, carregado no ficheiro anterior, encontra-se em /root/networks.lst. Este contem as lista das gamas das redes locais do IPN. A3.R3 Anexo 8.odt Página 5/9

99 Servidores com NAT na Firewall Estão configurados na Firewall do IPN, várias interfaces virtuais com endereço público a usar NAT directamente para os IP's internos de certas VLAN's. Isto faz com que a leitura de tráfego no link da Firewall, verifique o mesmo tráfego do exterior para essa interface virtual e daí para os IP's internos, isto para a entrada de tráfego. Para a saída de tráfego para o exterior, procede-se de modo análogo em sentido inverso. Assim, no filtro do libpcap, é necessário adicionar uma regra que evita que se contabilize o tráfego directo para a interface virtual, bastando para isso acrescentar um 'or' para outro endereço IP que representa essa interface, na expressão do filtro: and not (host <ip> or <ip>...). - Cenário físico de NAT do exterior para as VLAN's. Tanto o NTop como o PMACCT usam o mesmo filtro, pelo que será necessário manter estes dois iguais. Sempre que haja modificações nesta estrutura da rede, é necessário actualizar esse filtro para as duas aplicações de contabilização, capturarem apenas o que entra e sai para a Internet. Assim é necessário: 1.Editar os ficheiro /etc/init.d/ntop e /etc/pmacct.conf; configurar o filtro que é igual para os dois. 2.Fazer 'restart' a ambos: /etc/init.d/ntop restart /etc/init.d/pmacct restart Tarefas comuns NTop - Consultar estatísticas Esta aplicação apresentada uma grande variedade de dados para visualizar e a sua utilização é baste intuitiva. Aqui apenas se indicam as opções que possivelmente são mais úteis à equipa da USIC. A3.R3 Anexo 8.odt Página 6/9

100 NTop - Adicionar/Remover protocolo para monitorizar O NTop permite agrupar tipo de tráfego IP, em layer 3, isto é, classifica-o segundo os portos ou os nomes dos protocolos conhecidos e definidos em /etc/services. Assim é possível pré-definir que tipo de tráfego se pretende verificar nas tabelas do NTop. Todo o tráfego que aqui não seja definido, é considerado como 'Other-IP', ou seja, todo o resto que não esteja definido. A3.R3 Anexo 8.odt Página 7/9

101 NTop - Modificar a password do utilizador 'admin' Após autenticação, no portal do NTop é possível modificar a password do utilizador 'admin' na área de administração. No entanto, se esta for esquecida têm de se proceder da seguinte forma: PMACCT/BWstat - Consultar estatísticas A3.R3 Anexo 8.odt Página 8/9

102 BWstat - Modificar a password do utilizador 'admin' Após autenticação, no portal do BWstat é possível modificar a password do utilizador 'admin' na área de utilizadores. No entanto, se esta for esquecida têm de se proceder da seguinte forma: NTop e PMACCT - Adicionar/Remover nova rede local É provável que no futuro haja mais redes internas para além das <gama-interna> e <gamaexterna>, pelo que ficam aqui os passos necessários para o NTop e o PMACCT reconhecerem as redes que são locais. A3.R3 Anexo 8.odt Página 9/9

103 Anexo 9 Título: Backups & Updates de sistema dos servidores instalados Contacto: André Ribeiro Estagiário ajoao@ipn.pt Controlo de Versões: Ref.: Data Alterações Responsável Documento inicial, a parte dos backups foi obtida dos manuais originais de cada servidor. André Ribeiro

104 Descrição Este documento foi elaborado de modo a completar os manuais de manutenção dos três servidores colocados em produção, uma vez que os procedimentos de backups e updates foram exactamente iguais para todos devido ao SO instalado ser Gentoo Linux em todos eles. Quanto às bases de dados usadas, como são todas MySQL, o método de backup e restauro também é igual, mudando apenas o seu nome. Assim quando a indicação de <server> surgir, representa o seguinte: 'wifi', 'print' ou 'shaper', sendo respectivamente o servidor Wireless, o de impressões e monitor de tráfego. E quanto ao nome das bases de dados a usar temos <namedb> em que existem: 'radius' de contas temporárias no servidor 'wifi'; 'pykota' impressões dos utilizadores nas impressoras; 'bwstat' do tráfego que o PMACCT guarda. Backups Imagem do sistema Para criar um ficheiro.tgz de backup do servidor <server> em funcionamento, numa máquina Linux remota, com o RSync instalado, executou-se o seguinte comando: > rsync -Saq --numeric-ids --exclude=/proc --exclude=/sys -e 'ssh -c blowfish' <server>.ipn.pt:/ <server>/ De seguida, colocou-se a pasta '<server>' num ficheiro.tgz > tar czvf <server>.tgz <server>/* Backup e restauro da base de dados Para efectuar backup da base de dados e respectivo restauro, procede-se da seguinte forma: Anexo 9.odt Página 2/3