Universidade de Lisboa Faculdade de Ciências Departamento de Informática

Transcrição

1 Universidade de Lisboa Faculdade de Ciências Departamento de Informática Estudo de melhorias ao nível do desenho da arquitectura da rede do DI projecto realizado no Departamento de Informática da FCUL por Nuno Miguel Lopes Marques Mestrado em Engenharia Informática 2007

2 2

3 Universidade de Lisboa Faculdade de Ciências Departamento de Informática Versão pública, sem anexos de: Estudo de melhorias ao nível do desenho da arquitectura da rede do DI projecto realizado no Departamento de Informática da FCUL por Nuno Miguel Lopes Marques Projecto orientado pelo Prof. Dr. António Casimiro e co-orientado por Eng. Nuno Fernandes Mestrado em Engenharia Informática 2007

4

5 Declaração Nuno Marques, aluno n o da Faculdade de Ciências da Universidade de Lisboa, declara ceder os seus direitos de cópia sobre o seu Relatório de Projecto em Engenharia Informática, intitulado Estudo de melhorias ao nível do desenho da arquitectura da rede do DI, realizado no ano lectivo de 2006/2007 à Faculdade de Ciências da Universidade de Lisboa para o efeito de arquivo e consulta nas suas bibliotecas e publicação do mesmo em formato electrónico na Internet. FCUL, 23 de Junho de 2007 Nuno Fernandes, supervisor do projecto de Nuno Marques, aluno da Faculdade de Ciências da Universidade de Lisboa, declara concordar com a divulgação do Relatório do Projecto em Engenharia Informática, intitulado Estudo de melhorias ao nível do desenho da arquitectura da rede do DI. Lisboa, 23 de Junho de 2007

6

7 Resumo O suporte para qualquer sistema informático moderno passa por uma rede de computadores, rede essa que permite ligar o utilizador aos recursos de que este necessita. O mau funcionamento da rede informática que suporta a operação de uma instituição, implica grandes impactos na produtividade dos seus funcionários. Assim, existe a tendência para não fazer alterações que possam provocar algum problema temporário, levando a rede a ficar obsoleta devido à falta de actualizações. Neste documento é apresentada uma forma de modernizar uma rede informática de uma forma planeada e faseada, minimizando o tempo de indisponibilidade. Foca-se o caso particular da rede informática do Departamento de Informática da FCUL. Essa modernização terá de ser feita tendo em conta alguns objectivos, nomeadamente a garantia de alta disponibilidade dos serviços críticos, o aumento do desempenho de alguns serviços e a concretização de novos serviços que complementam a oferta já existente. Para atingirmos os objectivos pretendidos teremos de percorrer várias fases, desde o levantamento de todos os serviços existentes, à selecção dos que são realmente necessários e não apenas serviços redundantes e supérfluos, passando pela definição de uma estratégia a seguir de forma a melhorar a oferta de serviços e a criar novas soluções. Este documento descreve o projecto realizado no âmbito da disciplina Projecto em Engenharia Informática do Mestrado em Engenharia Informática da Faculdade de Ciências da Universidade de Lisboa. PALAVRAS-CHAVE: rede de computadores, arquitectura, segurança, administração, desenho, monitorização i

8

9 Abstract Every modern computer system is typically a networked system, where the network connects the user to any resource she needs. A problem or malfunction in the network implies great losses on employees productivity. Therefore systems administrators are sometimes lead to leave the network alone, without changing anything, in order to avoid the possibility of creating temporary problems. This will lead to an obsolete network due to lack of updates. In this document we show how to update a computer network in a phased way, with proper planning, while minimizing the downtime. We focus on the specific case of the FCUL Department of Informatic network. These updates will be done in order to acomplish the following objectives: high availability of critical services, higher performance of some services and provision of new useful services. To acomplish these objectives we will have to survey currently existing services, which of these are really necessary and not redundant or superfluous, and then we must choose a strategy that leads to better services and new solutions. This document describes the project realized in the scope of Informatics Engineering Masters of FCUL. KEYWORDS: computer network, architecture, security, administration, design, monitoring iii

10

11 Conteúdo Lista de Figuras Lista de Tabelas ix xi 1 Introdução Motivação Objectivos Organização do documento Remodelação da rede Análise do contexto actual A realidade Análise da rede Elementos essenciais Serviços da DMZ Importância da redundância Plano de migração Gateways Proxys de Proxys Web Configuração de mecanismos de redundância Implementação Submarino Cuttysark Proxy de Serviços críticos Outros serviços Outros Projectos VPN PPTP vs OpenVPN Número de Servidores v

12 3.1.3 Utilização Implementação Proxy Listas de Migração Criação de áreas Computadores externos ao DI Monitorização Nagios SNMP Logwatch Cacti Syslog Uniformização de configurações Configurações locais Configurações remotas Switches Projectos futuros Honeypot IPv Traffic Shaping Compile Farm Endereços de switches Wiki Conclusão 43 Bibliografia 45 Appendices 47 A Antigo Diagrama da Rede 47 B Diagrama da Rede Actualizado 48 C Rede Futura 49 D VLANs e Subredes 50 E Rotas nas Gateways 51 F Políticas de Firewall 52 vi

13 G Normalização de Serviços 53 H Configurações locais 54 vii

14

15 Lista de Figuras 3.1 Excerto de uma mensagem do Nagios Interface web do Nagios Excerto de uma mensagem do Logwatch Screenshot da interface web de um switch HP A.1 Antigo diagrama da rede B.1 Diagrama da rede actualizado C.1 Diagrama da rede futura ix

16

17 Lista de Tabelas 2.1 Latência na rede dos alunos D.1 Lista de VLANs D.2 Subredes E.1 Rotas da Submarino E.2 Rotas da Cuttysark E.3 Rotas da GW-DMZ xi

18

19 Capítulo 1 Introdução Perceber como se moderniza uma rede informática de uma forma gradual e estratégica leva a que seja necessária uma extensa análise da rede existente, dos pontos fortes e sobretudo dos pontos fracos, para serem melhorados. É preciso perceber a componente humana da rede, tentar minimizar o impacto nos hábitos dos utilizadores, mas não deixar tudo na mesma só para não alterar a forma de fazer algo. Depois da análise há que planear o processo de melhoramento, perceber quais os serviços a manter, quais os sistemas que estão obsoletos, que novos serviços poderão melhorar a produtividade dos utilizadores. Por fim há que implementar o plano traçado, o que deverá ser feito causando o menor impacto possível no trabalho dos utilizadores, podendo isto ser problemático aquando da migração de servidores críticos. Testar todos os sistemas antes de os colocar em produção, de preferência com alguns utilizadores reais, escutar o que estes têm a dizer sobre o sistema final, pois é para eles que a rede existe e não para os administradores de sistemas. Este trabalho foi realizado no contexto da modernização da rede informática do Departamento de Informática da Faculdade de Ciências da Universidade de Lisboa, para isso o autor exerceu o papel de Técnico Informático na Administração de Sistemas 1 do DI. 1.1 Motivação A grande motivação para este trabalho advém da vontade de perceber como fazem as grandes empresas que têm um enorme parque informático, com níveis elevados de disponibilidade, estando, no entanto, continuamente a modernizar esse mesmo parque. Não só perceber como modernizar uma rede, mas perceber o que deverá ser alterado nessa rede e de que forma isso deverá ser feito. E de que forma 1 Designada neste relatório por admin 1

20 Capítulo 1. Introdução 2 essa metadologia poderá ser aplicada à rede do DI. 1.2 Objectivos Pretendemos efectuar um plano que permita alterar a estrutura da rede causando o mínimo de indisponibilidade, e implementar algumas das soluções apresentadas durante o decorrer deste relatório. O plano deverá conter, especificamente: Estudo da reestruturação da rede Definição da estratégia a seguir aquando da reestruturação da rede Listagem dos serviços a migrar Listagem de novos serviços que serão implementados 1.3 Organização do documento Este documento está organizado em quatro capítulos, sendo o primeiro a introdução. No segundo capítulo apresentamos a análise efectuada às condições da rede e descrevemos a estratégia a seguir na reestruturação. Discutimos as diversas hipóteses consideradas para a futura organização da mesma e razões que levaram à escolha final. Por fim, falamos de alguns casos que já implementámos. O terceiro capítulo apresenta outros projectos realizados na administração de sistemas que foram importantes no contexto do bom funcionamento de toda a infraestrutura. Por último, a conclusão, é apresentada no quarto capítulo.

21 Capítulo 2 Remodelação da rede The engineer s first problem in any design situation is to discover what the problem really is. Autor Desconhecido 3

22 Capítulo 2. Remodelação da rede Análise do contexto actual Half of analysis is anal. Marty Indik O conhecimento da situação da rede informática do DI foi iniciado com recurso a um relatório[1] existente. Este relatório foi uma grande ajuda para tomar o pulso à situação actual, possibilitando ter uma ideia sobre que tipo de serviços o DI disponibiliza, quantos servidores tem e que sistemas utiliza. Serviu também para apresentar o desenho da rede informática (Figura A.1). Este relatório ilustra a importância de haver documentação, facilita a inserção de novos elementos na admin, mas também facilita o trabalho de quem mantêm a rede no dia a dia. Por outro lado, um aspecto negativo que detectámos neste relatório consistiu na desactualização de alguma informação. No diagrama referido anteriormente estão representadas muitas máquinas que já não existem na realidade. Quanto mais um administrador de sistemas tem de puxar pela memória ao olhar para a documentação, pior esta se encontra. Se não tiver de pensar quais os sistemas que já foram abatidos, quantos foram introduzidos, em que subrede foram inseridos, que serviços têm ou qual o seu endereço IP, a sua tarefa fica muito mais fácil e a sua produtividade certamente aumentará bastante. O site da administração de sistemas 1 tem também alguma documentação sobre procedimentos. Contudo, esta informação encontra-se desactualizada e em alguns casos incompleta A realidade Para conseguir analisar a rede é preciso saber como ela está desenhada. Assim o primeiro passo é actualizar o diagrama de rede (Figura B.1). Com o diagrama podemos ver como ser distribui a rede e um dos primeiros aspectos que salta à vista é a centralização de toda a rede num único nó, o di-gate. Se este nó falha todos os serviços falham, sendo por isso o nó mais crítico da rede. Existe um nó semelhante na rede dos alunos, a chalupa, mas se este servidor falhar apenas os alunos ficarão sem rede. Assim a rede divide-se em três zonas: zona de alunos, que são servidos pela chalupa, zona de redes de investigação e o resto do DI, que são servidos pela di-gate. A rede do DI subdivide-se noutras subredes: Docentes / Funcionários 1

23 Capítulo 2. Remodelação da rede 5 Rede dos computadores pessoais dos docentes 2, que contém também o servidor de /shell para docentes. Servidores Todos os servidores que apenas fornecem serviços para dentro da rede estão aqui. DMZ Servidores que oferecem serviços ao mundo. Admin Esta subrede contém as máquinas pessoais dos membros da administração de sistemas, assim como o servidor de /shell da admin e servidores de backups. Por seu lado a rede dos alunos tem duas subredes: Servidores Máquinas que oferecem serviços destinados a alunos Labs Máquinas dos laboratórios e alguns servidores As redes das unidade de investigação são redes autónomas sobre as quais a admin não tem responsabilidades. Para termos uma melhor noção sobre o tipo de máquinas que efectivamente integravam o nosso parque informático, foi feito um relatório sobre todos os servidores em funcionamento e suas características. Essas características contêm entre outros aspectos: Sistema Operativo (SO) e respectiva versão Serviços oferecidos Estrutura de partições e espaço disponível Capacidade do processador e memória Placas de rede e respectivos endereços IP Utilizadores autorizados a fazer sudo (quando SO é Linux) 2 Futuramente quando nos referirmos a docentes estamos também a referir-nos a funcionários.

24 Capítulo 2. Remodelação da rede 6 Com este relatório ficámos com uma ideia de que servidores precisavam urgentemente de um upgrade, assim como quais os serviços que tínhamos numa versão já obsoleta. Isto é fundamental para podermos planear as alterações e o trabalho a realizar. Não podemos modernizar o parque informático se não soubermos quais os servidores que estão obsoletos. Não se deve esperar que estes falhem para se começar a planear a sua migração. Tem de haver um plano temporal bem explícito sobre o tempo de vida de cada servidor. Claro que não basta ter um plano que diga em que dia vai ser migrado um determinado servidor. É preciso ter uma estratégia formada que diga quais os serviços que serão migrados, se iremos migrar tudo ou se alguns serviços já justificam um servidor próprio. Foi também executado um levantamento de todos os PC s que estão sob o nosso controlo, quais os seus MAC addresses e a quais tomadas de rede estão ligados. De seguida apurou-se qual o switch 3 e a que porta desse switch correspondia essa mesma tomada. Isto permite saber exactamente onde está ligado cada PC que esteja nos nossos laboratórios, o que foi indispensável para a execução do trabalho descrito na secção 3.5. nós 3 Dispositivo utilizado em redes de computadores para reencaminhar pacotes entre os diversos

25 Capítulo 2. Remodelação da rede Análise da rede Two wrongs don t make a right, but three lefts do. Autor Desconhecido Como se pode facilmente ver pelo diagrama de rede (Anexo B), a di-gate é um ponto fulcral da rede. Se este falha, toda a rede pára, sendo por isso um servidor altamente crítico. Isto aplica-se também à chalupa, visto que se esta parar de funcionar os alunos deixam de aceder a servidores situados fora da sua rede. Como tanto a di-gate como a chalupa são máquinas já algo obsoletas e bastante desactualizadas tanto a nível de software como de hardware, a ideia de as substituir começou a tomar forma, e uma das primeiras sugestões foi uma appliance 4. O outro problema é a nossa gama de IPs públicos, usamos IPs públicos para quase todas as máquinas quando não deveria ser assim Elementos essenciais Appliance Esta appliance faria o papel da di-gate, isto é, firewall e router, e serviria também como servidor de VPN. Como continuaria a ser o ponto crítico da rede seria interessante a possibilidade de adquirir duas appliances para funcionarem em redundância, garantindo assim serviço permanente desde que uma delas estivesse operacional. As appliances vêm já com um SO específico, devidamente alterado para permitir uma maior segurança, são fáceis de instalar e de configurar pois já têm interfaces gráficas, muitas vezes via web, que permitem configurar as regras da firewall ou de routing. A desvantagem é que este tipo de aplicações são extremamente caras, e como no nosso caso era importante ter duas para termos tolerância a faltas, torna-se duplamente caro, assim em vez de optarmos pelas appliances resolvemos adquirir servidores. Os servidores A decisão final foi a compra de dois servidores, com estes servidores e um outro já existente implementar-se-á uma rede em anel com três nós, assim se um dos nós cair haverá sempre um caminho alternativo 5. Optou-se por usar o sistema operativo FreeBSD 6, este sistema parece oferecer a melhor relação segurança/eficiência [2]. Para criação e manutenção das regras de firewall continuaremos a utilizar a aplicação 4 Appliances são aplicações que fornecem determinados serviços e que correm numa plataforma de hardware específica. 5 Caminho alternativo para a Internet, uma rede situada atrás de um servidor que esteja parado ficará sempre isolada 6

26 Capítulo 2. Remodelação da rede 8 que sempre utilizámos até aqui, o FWBuilder 7. Esta aplicação permite compilar regras de firewall para diversas plataformas, de uma forma fácil mas ao mesmo tempo permitindo regras complexas. Para tratarmos do encaminhamento de pacotes utilizaremos o software Quagga 8. Firewall Para criarmos as regras de firewall temos de começar por analisar as existentes, verificar quais as que têm sentido e se faltam algumas. As regras serão aplicadas a grupos de computadores (geralmente subredes) sendo que regras especificas serão de evitar. Todos os servidores deverão ter uma firewall particular, deixando apenas passar o tráfego para os serviços que oferecem, as regras particulares devem ser simples, por exemplo, se um servidor tem serviço de SMTP 9 então deverá aceitar ligações ao porto de todo o mundo, as regras presentes nas firewalls centrais é que deverão cortar ou deixar passar tráfego baseado na sua origem. Terão também de existir relações de confiança entre firewalls. Tráfego que venha do exterior para um dos servidores dos alunos não vai ser verificado pelas mesmas regras tanto na chalupa como na di-gate. Endereços Privados Com algumas excepções na rede dos alunos, todos os nossos servidores têm endereços públicos. Isto, além de ser um grande desperdício, é perigoso, pois em qualquer lado do mundo pode ser tentado um ataque contra o nosso Domain Controller, por exemplo, que apenas tem de oferecer serviços à rede interna. E ainda mais incompreensível é os computadores pessoais dos docentes/funcionários/admin terem endereços públicos Serviços da DMZ Uma DMZ ou demilitarized zone, é uma subrede que fica entre o exterior e a rede interna. É nesta subrede que ficam os servidores que oferecem serviços ao mundo 11, assim, se um deles for comprometido, o atacante ainda fica fora da nossa rede interna. Praticamente todos os nossos servidores externos residem nesta rede, mas nem todos Simple Mail Transfer Protocol - Protocolo utilizado para enviar e receber s 10 Porto onde o servidor de SMTP espera por pedidos 11 Doravante chamados de servidores externos

27 Capítulo 2. Remodelação da rede 9 As excepções Servidor NNTP 12 As regras na firewall tratam este servidor como se estivesse na DMZ, no entanto encontra-se na rede de servidores internos. Isto pode gerar alguma confusão. Servidores de Temos três servidores de , a sagres (mail.di.fc.ul.pt) que tem o dos docentes e funcionários, a caravela (mail.alunos.di.fc.ul.pt) serve os alunos e por fim a adamastor que tem o da administração de sistemas. Nenhuma destas máquinas está na DMZ, estando nas subredes correspondentes aos utilizadores que as utilizam. Servidor de FTP O servidor de FTP encontra-se na rede interna, além disso, serve de repositório de software de consumo interno. Este servidor deverá ser dividido em dois, um com o serviço de FTP, com acesso livre de todo o mundo e portanto situado na DMZ. O outro, com software de uso exclusivamente interno, na rede interna. Existem várias soluções possíveis para estes casos: Tudo na DMZ Colocar todos os servidores externos na DMZ. Com certos servidores funciona bem, como é o caso da VPN ou mesmo do servidor de NNTP, mas no caso da sagres ou caravela não faz sentido, pois estes contêm as áreas pessoais dos docentes e alunos. Proxys na DMZ Os servidores ficam na rede interna, mas na DMZ fica um proxy que reencaminha o pedido para os servidores correspondentes. Este caso funciona para prevenir ataques não relacionados com a aplicação que o servidor oferece ao mundo, pois se o ataque foi baseado num exploit dessa aplicação, automaticamente o atacante estará na nossa rede interna ao invés de estar na DMZ (isto se o proxy for um mero port forwarding) Importância da redundância É importante que alguns serviços apresentem uma disponibilidade elevada, para isso existe a redundância. A nosso ver os serviços mais críticos são o e a conectividade com o mundo. Assim vamos estudar formas de minimizar os riscos de estes serviços ficarem indisponíveis. 12 NNTP - Network News Transfer Protocol, também chamado apenas de news

28 Capítulo 2. Remodelação da rede Plano de migração In preparing for battle I have always found that plans are useless, but planning is indispensable. Dwight D. Eisenhower Para efectuarmos a migração com o mínimo de problemas, e visto que é uma mudança profunda na rede, elaborámos um plano. Com este plano esperamos minimizar o número de detalhes esquecidos e situações imprevistas Gateways A solução escolhida (Figura C.1) foi, como já referimos, a utilização de três gateways: Cuttysark Servirá os servidores internos, a rede da administração de sistemas e a rede dos docentes. Submarino Os PCs dos laboratórios e servidores dos alunos ficaram atrás desta gateway. Tem também uma saída secundária para a Internet. GW-DMZ Por fim a gateway que contém os nossos servidores externos, os laboratórios de investigação e a principal saída. Todas estas gateways terão software de firewall e routing Proxys de Para impedirmos que existam ligações do exterior directamente para a nossa rede interna, temos de implementar uma solução em que os pedidos sejam recebidos por uma máquina na DMZ e depois encaminhados para o servidor correspondente. Isto, para que os pedidos dos utilizadores internos não vão à DMZ, implica que o servidor de DNS externo aponte para esse ponto intermédio presente na DMZ, mas que o servidor interno aponte directamente para o servidor de . Assim, ao contrário do que acontecerá com as news, os pedidos internos não chegam a ir à DMZ, o que é importante visto que o tráfego de é mais sensível do que o de news. Então o passo lógico a dar seria criar três proxys na DMZ a fazer a ligação entre o exterior e os servidores de internos. Mas será essa a melhor solução?

29 Capítulo 2. Remodelação da rede 11 Perdition Existe uma aplicação criada especificamente para este tipo de situações, o Perdition 13 permite ter os túneis de que falávamos acima. E permite também ter uma estrutura em que recebamos todas os pedidos num servidor e depois, conforme o endereço de , envia para o servidor respectivo. Assim em vez de termos três proxys, temos apenas um que divide os pedidos para os servidores certos. Nginx Em alternativa ao Perdition existe a aplicação Nginx 14 que nos pareceu de mais fácil utilização e configuração. Optámos portanto em instalar este pacote na máquina nau - que já serve de proxy web de entrada. Redundância E se esse proxy pára? Do exterior é como se todos os nossos servidores de estivessem parados. Falaremos deste assunto na secção Proxys Web O objectivo da DMZ é ser uma rede que oferece serviços ao mundo, é por isso menos segura, visto necessitar de regras de firewall mais permissivas. Com a nossa mudança para endereçamento privado os únicos serviços que necessitariam de endereços IP públicos seriam os que estivessem na DMZ. Pois são os únicos a serem acedidos do mundo. Mas para os nossos utilizadores acederem à internet utilizam um proxy, esse proxy, como só disponibiliza serviços para a nossa rede interna não estará na DMZ e terá, portanto, um endereço IP privado. Mas com um endereço privado não conseguirá aceder à internet. Temos duas opções: 1. NAT Uma das soluções é fazer NAT, uma das gateways faria NAT para, e só para, o proxy. Tem a vantagem de ser simples de efectuar, as desvantagens são que a gateway precisa de manter uma tabela de estados para as ligações do proxy, tem portanto menor desempenho, e se porventura precisássemos que outro servidor interno acedesse directamente à internet, seria mais um a necessitar de NAT e o desempenho ficaria ainda pior MZ Outra solução é criar uma outra DMZ, que contenha servidores com endereços IP públicos, mas que não fosse acessível directamente de fora. Chamaremos a esta rede MZ 16. Trás a vantagem do tráfego para internet sair já com endereço Verdade seja dita, que com a capacidade das novas gateways esta perca de desempenho nunca seria notada. 16 MZ é uma sigla criada por nós, sem qualquer significado fora deste documento.

30 Capítulo 2. Remodelação da rede 12 público, não sendo portanto necessário fazer NAT, e se no futuro desejarmos criar novos servidores que acedam à internet, bastará coloca-los nesta subrede. Escolhemos a segunda opção. Para melhorar o desempenho optámos ainda por ter duas interfaces em cada um dos proxys, assim, terão um endereço público, por onde sairá o tráfego para a internet, e também um endereço privado, por onde chegarão os pedidos dos nossos utilizadores. Isto foi pensado para evitar que um pedido de uma página exterior faça três passagens nas nossas gateways, antes sequer de chagar à internet. Esta opção para melhorar o desempenho poderá trazer problemas a nível de segurança, se um atacante furar um proxy, terá uma forma directa de aceder à nossa rede interna. É portanto essencial que o tráfego de entrada na MZ seja apenas respostas a pedidos internos, todo o tráfego que não se relacione com pedidos pendentes terá de ser cortado. Idealmente todo o tráfego vindo do mundo seria cortado, infelizmente devido à menos boa forma de funcionamento de alguns serviços 17, certos portos poderão ter de ser abertos. Todo o tráfego com origem nesta rede e com destino a rede interna, deverá ser igualmente cortado. Com estas regras o risco associado a esta opção será mínimo Configuração de mecanismos de redundância É importante que alguns serviços apresentem uma disponibilidade elevada, para isso existe a redundância. Utilizámos o Nginx para ter apenas um servidor de visível (Secção 2.3.2), mas poderemos ter também redundância/load balancing 18, assim decidimos ter dois proxys. O primeiro passo é criar os nomes dos dois servidores a nível de DNS: mail mail IN A SERV1 IN A SERV2 Onde SERV1 é o IP do primeiro servidor e, surpresa das surpresas, SERV2 corresponde ao IP do segundo servidor. Como têm o mesmo nome, os pedidos serão atribuidos alternadamente às duas máquinas. Com este esquema garantimos não só redundância, pois se um servidor parar, a segunda tentativa irá para o outro, mas também load balancing, em que a carga será distribuída pelos dois servidores. 17 FTP por exemplo 18 Por load balancing entende-se dividir a carga, normalmente suportada por um servidor, por dois ou mais servidores

31 Capítulo 2. Remodelação da rede 13 MX secundário Para termos a garantia que nenhum se perde caso o nosso servidor de MX 19 esteja indisponível, é necessário termos um MX secundário. Para isto acontecer, faremos um procedimento similar ao que utilizámos para garantir redundância no Nginx (Secção 2.3.4), ou seja, introduziremos uma nova entrada no servidor de DNS, mas com uma prioridade diferente e do tipo MX: ZONA IN MX PRIORIDADE NOME. Em que ZONA é a zona de que o servidor serve, PRIORIDADE é um número que indica a prioridade do servidor, tem de ser maior (o número, menor prioridade) do que o do servidor principal, e o NOME é o nome do servidor MX secundário. Esta linha irá ser repetida para as diversas zonas que o MX irá servir. Este novo servidor de MX irá ficar situado numa máquina virtual, pois não se prevê uma utilização sistemática do mesmo. DNS exterior secundário Mas por muita redundância de serviços que tenhamos, se o servidor de DNS externo parar, todos os serviços param, trazendo por terra o nobre esforço para garantir os serviços activos. Portanto temos de garantir que o nosso DNS externo também é redundante. Para isso, em colaboração com o Centro de Informática 20, criámos um servidor de nomes secundário num dos seu servidores de DNS. Como a rede do CI é independente na nossa, mesmo que a rede do DI esteja parada, temos um servidor de nomes activo. Para a maioria dos serviços isto não interessa, pois estarão inacessíveis que qualquer forma, mas existem casos em que o nosso DNS aponta para recursos de outras instituições, que desta forma se manterão acessíveis. Saída secundária Uma outra saída é essencial para garantir disponibilidade caso a ligação do CI 21 falhe. Essa disponibilidade perde-se se não for feita automaticamente em caso de falha da saída primária. Antes de tudo é necessário adquirir um pacote de acesso à internet, de preferência com taxas elevadas de downstream sendo a taxa de upstream secundária, pois quando a utilização desta saída estiver activa, os serviços que oferecemos ao mundo ficarão inacessíveis, só servindo mesmo para utilização da internet. 19 Mail exchanger - Servidor responsável por receber os s do exterior e reencaminhá-los para os servidores correspondentes 20 Entidade que gere os recursos informáticos de toda a faculdade, futuramente designado por CI 21 Ou a da FCCN, que é a entidade que fornece a ligação ao CI

32 Capítulo 2. Remodelação da rede 14 Esta saída será feita através de um modem ligado ao GW-DMZ, este servidor será responsável por fazer NAT 22. O NAT é necessário para traduzir o endereço já público do proxy para outro endereço IP do ISP a que adquirimos a linha secundária. Isto terá de acontecer para que as respostas aos pedidos sejam encaminhadas por este ISP e não via FCCN, se isso acontecesse nunca cá chegariam. 22 NAT - Network Address Translation

33 Capítulo 2. Remodelação da rede Implementação If you believe in what you are doing, then let nothing hold you up in your work. Much of the best work of the world has been done against seeming impossibilities. The thing is to get the work done. Dale Carnegie Submarino A ideia inicial era efectuar a passagem para três routers principais de uma só vez, mas migrámos a chalupa primeiro. Esta migração ocorreu porque foi verificado que a rede dos alunos apresentava latência elevada e chegou-se à conclusão que o problema estaria no facto de a máquina chalupa ser obsoleta. Procedemos portanto à instalação do sistema operativo FreeBSD 6.1, optou-se por uma instalação inicial mínima, adicionando-se pacotes à medida que fossem precisos. Depois de instalado o software necessário foram configuradas as interfaces de rede de uma forma similar à da antiga chalupa, mas em vez de as rotas serem adicionadas só ao SO foi instalado o Quagga e as rotas foram adicionadas com base neste software, isto foi feito na esperança de quando instalarmos os outros dois routers a passagem seja facilitada. Após toda a configuração o submarino foi lançado e com isso a conseguiu-se uma grande diminuição da latência da rede, como se pode comprovar pelo output dos pings retirado antes e depois da migração (Tabela 2.1). Antes Depois 64 bytes from luna (...) time=3.43 ms 64 bytes from luna (...) time=0.461 ms 64 bytes from luna (...) time=4.79 ms 64 bytes from luna (...) time=0.601 ms 64 bytes from luna (...) time=4.88 ms 64 bytes from luna (...) time=0.506 ms 64 bytes from luna (...) time=4.86 ms 64 bytes from luna (...) time=0.554 ms 64 bytes from luna (...) time=3.38 ms 64 bytes from luna (...) time=0.659 ms Tabela 2.1: Latência na rede dos alunos Como se pode constatar pelos dados da tabela 2.1 ficámos com a rede sete vezes mais rápida após a migração Cuttysark Fomos obrigados a migrar a di-gate devido a problemas graves no seu funcionamento. Instalámos a cuttysark com FreeBSD 6.2, optámos por usar o sistema Packet Filter 23 para a firewall. As rotas, nesta primeira fase, ficaram estáticas, aquando da remodelação implementaremos rotas dinâmicas para tolerância a falhas. 23

34 Capítulo 2. Remodelação da rede 16 A migração foi executada numa noite, e pode-se considerar bem sucedida pois quase ninguém se apercebeu da mudança Proxy de Instalámos a última versão disponível na altura (nginx ) e configurámosla para receber pedidos de IMAP e POP3 com SSL. Usámos os certificados já em funcionamento no servidor de existente. O nginx funciona da seguinte forma: 1. Recebe um pedido 2. Envia os dados que recebe (username, password,...) para uma página web interna 3. Nessa página (construída por nós) tratamos esses dados e descobrimos qual é o servidor de correcto (existem quatro possibilidades - lasige, docentes, administração e alunos). Enviamos esse servidor de volta ao nginx, ou uma mensagem de erro caso o par username/password não seja válido. 4. O nginx liga-se ao servidor correcto e serve de proxy para o resto dos pedidos. Para que este processo se realizasse foi necessária a configuração de diversos stunnels 24 entre a nau e os respectivos servidores de , visto que o nginx não suporta SSL na comunicação com os servidores. Na página web que esta aplicação usa para descobrir o servidor de correcto foi usado código já existente, que consiste em ir aos diversos Active Directories descobrir a que classe pertence um dado username. O que ganhámos com o Nginx Após a entrada em produção deste sistema ganhámos em segurança e simplicidade. Ficou mais seguro pois os servidores de não precisam de receber ligações de todo o mundo, mas apenas ligações internas. Qualquer tentativa de aproveitamento de um exploit do servidor de vai ser tentado no proxy que está na DMZ, se essa tentativa tiver sucesso, o atacante ganha uma máquina numa rede em que não confiamos, em vez de entrar logo na rede protegida. A simplicidade advém do facto de qualquer docente/funcionário/aluno poder usar o mesmo endereço do servidor de , ao invés de cada uma destas classes de utilizadores usar o seu próprio endereço, como acontecia até aqui. 24 Aplicação que cria um túnel seguro entre duas máquinas

35 Capítulo 2. Remodelação da rede Serviços críticos O primeiro serviço a receber as mudanças, visto que a mudança mais profunda é a nível de gateways, é o routing. O que antes era encaminhado por apenas um nó central vai passar a ser encaminhado por vários. Com a mudança de grande parte da rede os serviços de DHCP e DNS também vão ter que ser bastante alterados. Obviamente vão ser necessárias alterações em todas as máquinas que irão mudar para endereçamento privado. Configuração IP Em todas as máquina cujo endereço será alterado, terá de ser alterado o seguinte: 1. endereço IP 2. máscara de rede 3. gateway 4. todos os ficheiros de configuração onde o endereço IP dessa máquina (ou de outra que também será alterada) esteja hardcoded 5. servidores DNS 6. servidor NTP Routing Em primeiro lugar há que garantir que a rede fica bem configurada. Numa primeira fase esqueceremos (nunca completamente mas apenas em termos de implementação) a parte que diz respeito a rotas alternativas. Quando a rede estiver funcional, mas antes de entrar em produção, iniciaremos a implementação de rotas alternativas. Para colocar as rotas em funcionamento utilizaremos o software, de que já falámos, Quagga. A sua configuração seguirá os seguintes passos: 1. telnet localhost 2601, enable e configure terminal Com estes comandos entramos numa consola de configuração do Quagga. 2. ip route REDE INTERFACE [DISTANCE] Para configurarmos as rotas usamos este comando podendo, ou não, atribuir pesos a cada uma delas. Como já referimos, nesta fase criaremos apenas as rotas indispensáveis. Por isso a opção DISTANCE será apenas utilizada depois de a rede estar funcional, para permitir configurar rotas alternativas.

36 Capítulo 2. Remodelação da rede 18 Endereçamento Decidimos passar a totalidade dos PCs e grande maioria dos servidores para endereços privados. Optimamente apenas os servidores presentes na DMZ e os proxys HTTP ficariam com IPs públicos. Para efectuarmos esta operação são precisas várias alterações: DHCP DNS Rotas Regras de firewall Algumas configurações nos switches Terão de existir também alterações por parte de utilizadores que, pelas mais variadas razões, tenham utilizado o endereço IP em vez de um nome para se referirem a uma máquina cujo IP passará para privado. Após a reestruturação de endereços a rede ficará dividida da forma presente na tabela D.2. Firewall É necessário actualizar os endereços de todas as máquinas e redes. Embora o desenho da rede tenha mudado, a sua organização lógica mantêm-se (DMZ, Servidores, Docentes,...), assim as regras continuam correctas, apenas com os endereços errados. Depois de verificado o bom funcionamento da firewall, é a altura indicada para rever e limpar as regras que já não fazem sentido, pois as regras da antepara de segurança já não são revistas há muito tempo. Deverá ser adicionada uma regra que impeça todo o tráfego baseado em IPv6. Neste momento não temos nenhum serviço a funcionar neste protocolo, se eventualmente viermos a ter, criaremos regras específicas para ele. Entretanto todo o tráfego IPv6 que chegar à firewall é assumido como malicioso. As futuras regras de firewall são apresentadas no anexo F. DHCP Depois de todos os servidores estarem acessíveis (nenhum servidor usa DHCP) 25 temos de alterar as configurações de DHCP para os computadores cujo endereço mudou. Poderão parecer mais alterações do que na realidade são precisas, na grande maioria dos casos o DHCP usa o DNS para obter o endereço IP a atribuir. Deverão ser alterados os servidores corveta e iate. 25 Existem uma ou duas excepções à regra, mas não são serviços críticos

37 Capítulo 2. Remodelação da rede 19 DNS Aqui deverá ser onde mais alterações serão precisas, para todas as máquina que foram alteradas é necessário actualizar os endereços. É uma tarefa fácil mas extensa. Deverão ser alterados os servidores corveta e flotilha. O servidor iate é escravo da corveta, por isso ao alterarmos a corveta estamos ao mesmo tempo a alterar os nomes da iate. Ao terminarmos estes passos deveremos ter uma rede funcional, mas grande parte dos serviços não funcionarão Outros serviços No anexo G é apresentado um conjunto de procedimentos a realizar para que os todos os serviços fiquem operacionais. Testes Para verificar o correcto funcionamento da rede vamos enumerar alguns testes a efectuar após a migração: Web Navegação na internet possível através do proxy de alunos e docentes, e impossível directamente (sem usar proxys). Acesso a sites internos da faculdade (por ex. intranet.fc.ul.pt) é possível. Páginas internas Servidores web a funcionarem correctamente para dentro e fora do DI. Login em admin.di.fc.ul.pt, horde.di.fc.ul.pt e myco. di.fc.ul.pt é possível. Páginas das cadeiras acessíveis. Páginas dos grupos de trabalho, por ex: ipm000, a funcionar. Servidores de , de alunos, funcionarios e admin, a funcionar através de POP3 e IMAP. Envio de (para dentro e fora do DI) através da smtps com contas de docentes e alunos. (de dentro e fora do DI) é entregue correctamente. Listas e aliases funcionam correctamente.

38 Capítulo 2. Remodelação da rede 20 Impressoras Correcto funcionamento das impressoras, testar impressões a partir dos laboratórios para a reprografia. Imagens Verificar que a obtenção de endereço IP, carregamento de imagens e login nos PCs decorre normalmente. É possível aceder à área de aluno através de Windows e Linux. Áreas de grupo a funcionar. Partilhas Acesso às partilhas de samba é possível, e a diferenciação (a nível de privilégios) é feita. Backups Verificar o normal funcionamento dos backups. Verificações finais Depois de feitas todas estas alterações a rede deveria estar completamente operacional. É aconselhável correr a aplicação tcpdump 26 nas gateways para verificar se alguma máquina está a tentar aceder a um endereço IP antigo. Este processo poderá também ser feito recorrendo aos logs da firewall. É expectável que, caso existam problemas, estes surjam das máquina dos utilizadores que, por alguma razão, terão um endereço IP hardcoded. Após atingido um funcionamento aceitável, é recomendada a execução de um port scanner 27 para verificar que as regras de firewall foram correctamente remodeladas Por exemplo o nmap (

39 Capítulo 3 Outros Projectos God is not dead but alive and well and working on a much less ambitious project. Autor Desconhecido 21

40 Capítulo 3. Outros Projectos VPN Uma VPN ou Virtual Private Network cria uma rede virtual cifrada que liga duas redes distintas. Por exemplo: Uma empresa, sediada em Lisboa, tem um escritório no Porto que poderá aceder a recursos privados, localizados na sede, através de uma VPN, com a garantia de que todo o tráfego entre a sede e o escritório vai cifrado. Este serviço já era disponibilizado pelo nosso departamento há algum tempo, mas uma vez que os servidores encontravam-se obsoletos procedeu-se à sua migração. Até aqui os servidores de VPN baseavam-se na implementação PPTP da Microsoft, ao planearmos a migração deste serviço pensámos se não haveriam vantagens em optarmos por outra implementação de VPN. Aí surgiu a ideia de usar OpenVPN PPTP vs OpenVPN A grande vantagem do PPTP sobre a OpenVPN é a facilidade de utilização em Windows sem necessidade de instalação de programas externos. Mas para outros sistemas é mais fácil a instalação do OpenVPN do que a de PPTP. O PPTP utiliza um protocolo IP (GRE) por vezes barrado em firewalls o que torna complicado/impossível colaboradores utilizarem serviços do DI quando estão em instituições que implementam essa politica. O OpenVPN é uma solução baseada em SSL sobre IP com possibilidade da utilização de um proxy para contornar estes possíveis problemas. Tem de ser possível criar uma ligação VPN de qualquer parte do mundo, o que não equivale a dizer que qualquer pessoa do mundo pode tentar criar uma ligação VPN para o DI. Isto acontece com o PPTP ficando assim vulnerável a ataques de força bruta. Com o OpenVPN o pedido de ligação só é aceite caso o cliente apresente um certificado válido, após esse passo é ainda necessário a utilização de username/password. Isto traz o inconveniente de o cliente ter que fazer o download do certificado de cada vez que utilizar uma máquina diferente mas traz grandes vantagens em termos de segurança. Aprofundamos este assunto na secção Número de Servidores Optou-se por utilizar apenas um servidor de VPN ao invés de dois como até aqui (um para alunos e outro para docentes). A separação de privilégios de acesso entre Alunos, Docentes, Administração e Investigadores é feita através de regras firewall presentes na própria máquina. Estas regras são possíveis visto que existem

41 Capítulo 3. Outros Projectos 23 quatro subredes, uma para cada tipo de utilizador, quando o utilizador efectua o pedido verifica-se qual a classe a que pertence e é-lhe criado um IP pertencente a essa subrede. Visto que não é possível ao cliente mudar o seu endereço IP remoto o respeito das regras é sempre garantido Utilização Para começar a utilizar a VPN os utilizadores têm de ir ao site da admin 1, depois de autenticados pedem a criação da conta. Após algum tempo a conta estará criada e o utilizador será avisado por que poderão fazer o download do pacote de instalação. O processo de criação de conta está completamente automatizado, visto que aquando do pedido temos a certeza que o utilizador foi correctamente autenticado pelo sistema, sendo portanto um utilizador válido. A autenticação dos utilizadores é feita na Active Directory, enquanto que os certificados são validados na CA 2 presente no servidor Implementação Ao configurar o servidor de VPN tivemos necessidade de tomar várias decisões: TUN vs TAP TUN e TAP são dispositivos de rede virtuais, simulam uma interface de rede mas na verdade enviam os pacotes para determinadas aplicações (que depois podem ou não enviá-los para a rede). TUN simula uma interface ponto-a-ponto enquanto que o TAP simula um dispositivo ethernet. Utilizámos TUN para garantir que todo o tráfego é efectuado ao nível de rede 3 de forma a ser correctamente filtrado pela nossa firewall. TCP vs UDP O OpenVPN permite que a ligação VPN seja feita utilizando o protocolo TCP ou UDP, optámos pelo TCP, embora haja uma ligeira perda de desempenho tem a vantagem de permitir utilizar um proxy entre o cliente e o nosso servidor. Isto é-nos especialmente útil quando um funcionário está num ambiente com regras de firewall bastante restritas que cortam o porto utilizado pelo OpenVPN, antes significava que não conseguiriam aceder aos nossos serviços internos, agora basta configurarem o cliente para utilizar o proxy da instituição onde se encontram Certification Authority 3 Nível 3 do Modelo OSI

42 Capítulo 3. Outros Projectos 24 Autenticação São várias as possibilidades para autenticação, só certificado, só username/password, uma password estática 4 e certificado, um certificado estático e password, certificado e password. Nós optámos pela última opção em que cada cliente tem um username/password (que já existem na AD) e um certificado sem password (o cliente poderá introduzir uma se o desejar): Aquando da criação de uma conta é gerado um certificado por uma CA, quando o cliente inicia a ligação apresenta as suas credenciais, aí será verificado se as credenciais foram geradas por um certificado proveniente da CA correcta. Se o cliente não apresentar um certificado válido os dados de autenticação (username/password) não serão utilizados, tornando impossível um ataque de força bruta sem um certificado válido. Após a validação do certificado é ainda pedido um par username/password, o username terá de ser o mesmo do que o inscrito no certificado do cliente, não sendo por isso possível com um certificado válido de um cliente entrar com os dados de outro cliente. Os dados serão verificados na AD e é ai que se determina o tipo de utilizador (Administrador, Funcionário, Aluno ou Investigador). É possível revogar um certificado fazendo com que este deixe de ser válido, por ter sido comprometido por exemplo. E se isso acontecer o cliente terá de fazer novo pedido de criação de conta. É também possível proibir certo utilizador de fazer pedidos de criação de conta, isto aliado à revogação de um certificado assegura que, se necessário, o utilizador fica sem acesso à VPN. As vantagens desta abordagem são que aproveitamos um esquema de autenticação já existente (AD) com todos os benefícios que este tem: expiração de password, limite de tentativas erradas num determinado espaço de tempo, desactivação de contas. Além disso, um certificado por cada cliente elimina quase completamente os perigos do ataque de força bruta, a única forma de ocorrer um ataque destes seria alguém comprometer um certificado de um utilizador e depois atacar a password desse utilizador. Para isto acontecer é já preciso ter uma noção de como o esquema de autenticação funciona. Claro que existem desvantagens, optámos por não obrigar os utilizadores a introduzir uma password no certificado, isto faz com que se o certificado for comprometido (por acção de um atacante ou desleixo do utilizador) estará logo apto a ser utilizado. Outra desvantagem é que os utilizadores poderão achar fastidioso ter 4 Com estático queremos dizer comum a todos os clientes

43 Capítulo 3. Outros Projectos 25 de descarregar o pacote de instalação para cada computador em que desejam fazer VPN. As vantagens dos certificados perdem-se um pouco devido à forma que temos de distribuição dos pacotes, visto que para efectuar o pedido de criação de conta de VPN ou para descarregar os pacotes o utilizador apenas precisa de se autenticar com username e password. Mas para um atacante tirar vantagem deste facto terá de ter conhecimento deste funcionamento, logo será um utilizador nosso que já tem acesso ao sistema, ganhando muito pouco em conseguir fazer VPN com outra conta. Outros serviços No servidor que oferece o serviço de VPN existem também os serviços de DNS e firewall. A firewall destina-se, como já foi referido, a executar uma separação de privilégios conforme o tipo de utilizador. Um novo serviço de DNS foi configurado nesta máquina por várias razões: Criar o subdomínio vpn.di.fc.ul.pt, o que nos permite ter uma maior organização, tornando fácil constatar que um determinado nome representa um IP na gama da VPN. Além disto, reduz as preocupações de conflitos com o serviço ainda existente a nível de nomes. O servidor de DNS tem apenas informação de nomes relacionados com a VPN, qualquer outro pedido é redireccionado para outros servidores DNS, isto torna possível que existam alterações aos servidores de DNS do departamento sem necessidade de alterar as configurações presentes nos clientes de VPN, bastando apenas alterar a configuração do servidor de DNS presente no servidor de VPN. Aquando da criação de uma nova conta de VPN é necessário criar uma entrada no DNS com a informação do IP atribuído e o nome correspondente, que terá a forma de USERNAME.vpn.di.fc.ul.pt. O facto de o DNS estar no local onde são criadas as contas facilita imenso a automatização de todo o processo. Binários Como o nosso ambiente é bastante heterogéneo é necessário dar suporte a diversos sistemas operativos, para isso acontecer, são criados pacotes para Windows, Linux e Macintosh: Windows Através do sistema NSIS 5 conseguimos construir um pacote específico para 5

44 Capítulo 3. Outros Projectos 26 cada cliente, contendo o certificado e ficheiros de configuração, assim como os próprios executáveis do OpenVPN. Tudo isto é feito no servidor em Linux. Linux Em Linux utilizámos o sistema makeself 6 que constrói um arquivo autoexecutável contendo todos os ficheiros necessários para a ligação. Aqui optámos por não incluir os binários do OpenVPN no pacote a distribuir, devido a cada distribuição ter a sua forma de instalar pacotes no sistema e maneiras de fazer actualizações. É portanto necessário instalar o OpenVPN no sistema antes de instalar os nossos pacotes que apenas contém ficheiros de configuração. Macintosh Para Macinstosh construímos um simples ficheiro zip contendo os ficheiros de configuração adequados ao sistema Mac OS X. Para utilizarem a VPN os utilizadores terão de instalar também a aplicação Tunnelblick 7 que já contém o OpenVPN. Outros Para outros sistemas disponibilizamos os ficheiros de configuração, e fica à responsabilidade do utilizador adaptar as configurações ao seu sistema. Quando o utilizador pede uma conta de VPN todos estes pacotes são criados, ficando disponíveis para download. Como é óbvio cada utilizador só poderá fazer o download dos pacotes criados para si. Página web Para facilitar a gestão do serviço foi criada uma página web que disponibiliza diversas informações sobre a utilização do mesmo (e.g. utilizadores registados, utilizadores online) além de um tutorial de como se executam alguns procedimentos específicos da VPN

45 Capítulo 3. Outros Projectos Proxy Todos os alunos que queiram utilizar a internet têm de utilizar um proxy. Para garantirmos que não usam os PCs só para fazer downloads, temos um política de quotas. Quota Neste momento a quota está definida como 1 GB mensal 8. As quotas são recalculadas diáriamente e se uma aluna exceder o tráfego que tem disponível, ficará sem acesso à internet e o valor excedentário passará para o mês seguinte. Este sistema já teria funcionado no passado, mas algures no tempo deixou de funcionar. Ao olharmos para os scripts existentes ficámos maravilhados com a confusão lá presente, decidimos portanto refazer a aplicação. Optámos por criar um grupo na Active Directory originalmente chamado de denysquid 9. Quando é detectado que uma aluna excedeu a quota é adicionada a esse grupo. A configuração do Squid foi feita de forma a que a autenticação de um aluno falhe se este se encontrar no grupo denysquid, sendo-lhe portanto cortado o acesso à internet. O grupo denysquid é limpo no inicio de cada mês. Para calcular o tráfego utilizado por cada aluno é utilizada a ferramenta Sarg 10. Esta ferramenta gera páginas HTML com os consumos de cada utilizador, para o fazer utiliza os logs do Squid. O script construído por nós lê as páginas geradas pelo Sarg para calcular o tráfego que cada aluno gerou até ao momento e insere esses valores numa base de dados. De seguida percorre a base de dados e coloca o aluno que ultrapassou a quota no grupo denysquid. Blacklist Temos também definidos na configuração do Squid alguns sites proibidos, entre eles encontram-se alguns sites de jogos e outros de biologia aplicada. Por politica não temos restringido sites mas temos a possibilidade de o fazer caso surja a necessidade. 8 O tráfego interno não conta para esta quota 9 Squid é o nome da aplicação que faz de proxy 10

46 Capítulo 3. Outros Projectos Listas de Existem diversos tipos de contas de . As contas normais, que cada utilizador tem, em que apenas são recebidos s para esse determinado utilizador e contas que reencaminham s para diversos utilizadores. Este tipo de s divide-se em duas classes: listas e aliases. 1. Aliases Os aliases são endereços de que redireccionam o para uma ou mais contas diferentes. Por exemplo, todos os s enviados para admin@di.fc. ul.pt são reencaminhados para todos os membros da admin. 2. Listas de As listas são uma versão avançada dos aliases, embora a essência seja a mesma: um enviado para uma lista é reencaminhado para várias contas de . Mas as listas oferecem outras funcionalidades: (a) Permitem aceitar ou rejeitar s (b) Fazem arquivo dos s recebidos, que poderão ser consultados em qualquer altura O servidor de listas de estava em estado crítico devido à falta de espaço em disco, decidimos portanto proceder à sua migração. Utilizámos a última versão disponível do sistema já em funcionamento chamado mailman 11, que é, em nossa opinião, o melhor sistema de gestão de listas Migração Para migrarmos as listas sem perder arquivos passados utilizámos a ferramenta rsync para copiar (e manter actualizados) os arquivos para a nova máquina. Depois criámos um script simples para criar todas as listas existentes e migrar os arquivos para essas listas. Teoricamente, esta seria a melhor altura para fazer uma limpeza das listas, retirando as que já não seriam necessárias, mas tal não foi possível. Devido ao carácter urgente da migração, não tivemos tempo de apurar quais as listas ainda activas. Decidimos então migrar todas as listas, e tratar dessa manutenção mais tarde. Para a migração ficar concluída bastou alterar todos os aliases de presentes na máquina mx de modo a apontarem para o novo servidor. Para a posteridade fica a linha que no Vi 12 permitiu fazer este passo sem nenhum stress : O melhor editor de texto de sempre

47 Capítulo 3. Outros Projectos 29 A migração foi um sucesso, pois alguns problemas que tinhamos nas listas antigas ficaram resolvidos (eram causados pela constante falta de espaço em disco) e a migração ocorreu de forma transparente para os utilizadores. Aproveitámos também para restringir o acesso à secção administrativa das listas à rede interna (VPN incluída claro). As passwords de administração das listas são demasiado fracas para esta componente estar aberta ao mundo. Importa também referir que este foi um dos primeiros serviços a entrar em funcionamento num servidor virtual.

48 Capítulo 3. Outros Projectos Criação de áreas O processo de criação de uma nova área tem de seguir os seguintes passos: O aluno preenche um formulário online, quando o formulário é preenchido com sucesso, são criados alguns scripts. Um dos scripts é um ficheiro ldif 13, com os dados do aluno a adicionar à AD. Existe também um bash script que cria a área do aluno na caravela. Por último o aluno tem que se deslocar à sala da administração de sistema para escolher uma password. É só neste momento que a conta é activada. Embora já existisse alguma automatização, para criar uma área era necessário ir ao servidor web, copiar os scripts para outros servidores (caravela e para um dos Domain Controllers) e executá-los. Isto pode parecer que não é trabalhoso, mas se tivesse que criar 100 novas contas certamente não pensaria assim. Assim, decidimos automatizar completamente o processo. Foi criado um novo utilizador na caravela (chamado god), que aceita ligações do servidor web da admin mediante apresentação de um certificado válido. Este utilizador é responsável por criar a home do novo utilizador e atribuir a respectiva quota. No nosso servidor web temos outro script cuja função é executar o script na caravela (através de SSH com o utilizador god) e adicionar o utilizador à AD, com o ldif criado anteriormente e o comando ldapadd. Por fim, e se não ocorreu nenhum erro, move os scripts de lugar para não serem executados outra vez. Portanto a criação de novas contas ficou reduzida à execução de um único script. 13 LDAP Data Interchange Format - formato utilizado para exportar/importar dados de um directório LDAP

49 Capítulo 3. Outros Projectos Computadores externos ao DI Até aqui qualquer aluno que trouxesse um portátil poderia desligar um dos PCs, situado num laboratório, da rede para ligar o seu. Isto é mau por duas razões: retira um posto de trabalho e o aluno fica com um PC capaz de ouvir o tráfego da rede em modo promiscuo. Para impedir isto precisamos de fazer com que seja inútil a ligação de um computador externo aos nossos pontos de rede. MAC address Os nossos switches têm a possibilidade de bloquear portas a MAC addresses, isto faz com que uma porta do switch só atribua rede a uma determinada placa de rede 14. Se um aluno ligar um portátil a uma tomada de rede pertencente a um PC dos laboratórios o switch não encaminhará os pacotes visto que o MAC address não é reconhecido. Para que isto pudesse acontecer foi necessário efectuar um levantamento de informação que contivesse todos os MAC addresses dos nossos PCs, a qual switch estavam ligados e nesse switch qual a sua porta. Os switches possibilitam trancar uma porta ao MAC address mesmo sem saber esse MAC address, ficando preso ao primeiro MAC address que tente utilizar essa porta. Se tivermos a certeza que não existem elementos exteriores nos laboratórios, isto facilita grande parte do trabalho. Isto faz com que os alunos não consigam ligar os portáteis nos pontos de rede utilizados pelos nossos PCs, mas conseguirão utilizar as tomadas livres. No entanto a questão de por a placa de rede em modo promíscuo ainda se mantém. VLANs Para deixar os alunos ligarem os seus portáteis nas tomadas de rede disponíveis, sem pôr em risco a privacidade dos utilizadores dos nossos PCs, optámos pela a utilização de VLANs. Uma VLAN (Virtual LAN) serve para criar redes lógicas independentes numa rede física. No nosso caso, ao pormos todas as tomadas de rede livres numa VLAN diferente da dos PCs dos laboratórios (vamos chamá-la VLAN EXT), os alunos da VLAN EXT que ponham a placa de rede em modo promiscuo apenas escutarão tráfego na VLAN EXT, ou seja, de outros alunos a utilizarem as tomadas livres. Ao ligar um portátil numa tomada livre este receberá um IP por DHCP, esse IP ficará numa gama com regras de firewall mais restritas do que os PCs dos laboratórios. 14 Não é bem assim visto que é possível mudar o MAC address

50 Capítulo 3. Outros Projectos 32 Wireless Utilizaremos a mesma VLAN que criámos para a ligação de portáteis à rede, através de uma tomada de rede, para os acessos por wireless. O AP 15 ficará ligado numa porta que pertence a essa VLAN, pelo que nenhum do tráfego gerado num PC de um laboratório passará pelo AP. O acesso à rede wireless está disponível para qualquer utilizador. o que terá de ser alterado para permitir o acesso apenas a utilizadores válidos do nosso departamento. Isto poderá ser feito de várias maneiras. VPN O utilizador liga-se à rede wireless e só tem privilégios para iniciar uma ligação VPN. Nessa ligação terá de se autenticar e além disso ficará automaticamente com todo o tráfego cifrado, e portanto, inacessível para os outros utilizadores. EAP 16 O utilizador providenciará um username e uma password que serão validados na AD. Optámos pela segunda opção, os nossos APs oferecem a possibilidade de, ao serem usados juntamente com um servidor RADIUS 17, poderem autenticar um utilizador e de seguida, colocá-los numa determinada VLAN. Esta é uma opção extremamente interessante visto que permitiria a diferenciação imediata, a nível do AP, dos privilégios dos diversos tipos de utilizadores. Por exemplo, um professor ao ligar-se consegue aceder por SSH à sua máquina, mas se for uma aluna a ligar-se, nem conseguirá fazer pings a essa mesma máquina. 15 Access Point - Antena wireless 16 Extensible Authentication Protocol 17 Remote Authentication Dial In User Service - É um protocolo de AAA (authentication, authorization and accounting)

51 Capítulo 3. Outros Projectos Monitorização É imperativo sabermos que temos problemas antes que comecem a chover telefonemas de utilizadores em fúria, para isso acontecer precisamos de ter software que faça monitorização. E não basta saber se uma dado servidor está em funcionamento, é também necessário saber se todos os serviços que ele oferece estão funcionais. Além disto, convém termos a noção se um serviço está a ser muito utilizado e se o seu desempenho é adequado Nagios O software Nagios 18 é bastante customizável, permitindo monitorizar uma grande quantidade de serviços além de dar a hipótese de criarmos plugins que monitorizem serviços específicos que o programa em si não vem preparado para monitorizar. No passado já tinha sido configurado um servidor com o Nagios, mas estava configurado para monitorizar poucos dos nossos serviços, sendo assim decidimos fazer uma nova instalação num novo servidor. Optámos também por instalar a aplicação NagiosQL 19 que permite configurar o Nagios através de uma interface gráfica. Depois de introduzidos no sistema todos os serviços (e respectivos servidores) o Nagios começa a monitorização, assim que detecta que um serviço não está a responder envia um a avisar com detalhes sobre o problema como exemplificado na Figura 3.1. ***** Nagios ***** Notification Type: PROBLEM Service: IMAPS Host: caravela Address: State: CRITICAL Date/Time: Wed Oct 25 10:46:55 WEST 2006 Additional Info: CRITICAL - Socket timeout after 10 seconds Figura 3.1: Excerto de uma mensagem do Nagios

52 Capítulo 3. Outros Projectos 34 Neste caso ficamos a saber que o serviço de IMAPS do servidor caravela não está a responder e podemos procurar de imediato as origens do problema mesmo antes de os utilizadores se aperceberem do mesmo. O Nagios volta a enviar um após n minutos se o serviço se mantiver em baixo, e avisa também caso o serviço volte ao normal. É também possível integrar o Nagios com SNMP de forma a monitorizar diversos parâmetros da máquinas, como por exemplo, o espaço em disco. O Nagios também oferece uma interface web que permite visualizar o estado do rede: Figura 3.2: Interface web do Nagios SNMP O SNMP é um protocolo que permite obter informação sobre um sistema de forma remota. Organiza-se em MIBs, são estas que contêm, de forma hierárquica, a listagem de informação que é possível obter através deste protocolo. O SNMP só por si não nos serve de muito, mas com aplicações que o utilizem, oferece aos

53 Capítulo 3. Outros Projectos 35 administradores de sistemas formas de controlarem os mais variados aspectos de um sistemas de uma forma bastante eficaz. Além disso permite, também remotamente, alterar parâmetros da configuração desses mesmos sistemas. Permite também o envio de traps, isto é muito útil para fazermos a monitorização de vários aspectos, como por exemplo o que discutimos na secção 3.5. Quando um utilizador liga um portátil numa tomada de rede ocupada por um PC, recebemos uma trap (na forma de ) a avisar do sucedido. Os switches enviam traps de cada vez que uma porta fica com ou sem rede, na maioria dos switches isto dá para desligar, mas noutros não dá. Portanto é aconselhável que a conta de que receber as traps tenha o procmail 20 configurado de forma a excluir certos tipos de traps. Se isso não acontecer, a quantidade de traps é tanta que se torna impossível de retirar informação útil das mesmas Logwatch Todos os servidores correm diáriamente uma pequena aplicação chamada Logwatch 21, este programa analisa diversos ficheiros de log e envia um sumário das suas entradas. Pode ser configurado com três níveis de detalhe (low, med, high) variando a quantidade de informação que envia. O sumário é enviado por (Figura 3.3), assim, se ocorrer algum problema, poderá ser encontrada a sua causa nos s recebidos. Uma visualização periódica dos s é também realizada de forma a garantir que nada de anormal se passa com os servidores Cacti Agora que temos o SNMP devidamente configurado e funcional seguimos para a parte mais vistosa de qualquer sistema informático: gráficos. Decidimos utilizar o Cacti 22, que permite traçar gráficos de tudo o que o SNMP permite aceder. Com isto podemos ter históricos de picos de utilização de memória, disco, interfaces de rede, etc, o que nos mostra que servidores estão com carga a mais e quais aqueles que estão a ser subaproveitados. Com este gráficos podemos visualizar que rumo está a utilização dos recursos a seguir, de forma a prever necessidades de upgrades futuros Syslog E se uma máquina for atacada, e o atacante, antes de sair, alterar os logs presentes na máquina? Aí nunca saberemos que a máquina está comprometida. Por 20 Programa de filtragem de s

54 Capítulo 3. Outros Projectos 36 ################### LogWatch (10/27/02) #################### Processing Initiated: Mon Nov 6 04:02: Date Range Processed: yesterday Detail Level of Output: 10 Logfiles for Host: paquete ################################################################ Disk Space Filesystem Size Used Avail Use% Mounted on /dev/sda6 4.8G 2.3G 2.3G 50% / /dev/sda1 99M 25M 68M 27% /boot none 314M 0 314M 0% /dev/shm /dev/sda7 4.1G 33M 3.8G 1% /tmp /dev/sda3 4.8G 689M 3.8G 15% /usr /dev/sda5 4.8G 56M 4.5G 2% /var /dev/sda2 14G 14G 429M 97% /var/log/squid Figura 3.3: Excerto de uma mensagem do Logwatch esta e por outras razões decidimos configurar um servidor de logs. Este servidor vai receber logs de todas as máquinas, e vai permitir analisá-los de uma forma centralizada.

55 Capítulo 3. Outros Projectos Uniformização de configurações Configurações locais Cada servidor tem o seu propósito portanto a sua configuração vai variar conforme os serviços que vai oferecer, mas existem sempre um conjunto de aspectos similares em todos eles. São essas configurações que deverão estar documentadas para ser mais fácil a sua implementação num novo servidor. Como não poderia deixar de ser, tudo começa com a escolha do SO, o parque informático do DI tem diversos sistemas operativos, desde RedHat Linux a Mandrake, de Gentoo Linux a Microsoft Windows. Isto gera alguma entropia devido ao facto de certos procedimentos se efectuarem de forma diferente nos vários sistemas. Por isso tem havido um esforço em uniformizar os sistemas operativos, a escolha recaiu sobre o CentOS 23. Este sistema é baseado no Redhat Enterprise Linux mas com a vantagem de ter updates sem ser necessário pagar por esse suporte. Assim, nos novos servidores Linux será sempre instalada esta distribuição. Configurações genéricas a serem usadas na maioria dos novos servidores podem ser encontradas no anexo H Configurações remotas Ao introduzirmos um novo servidor na rede é necessário configurar serviços presentes noutros servidores. Começando pelas óbvias alterações ao DNS, adicionando o nome e o IP aos já existentes, passando pelo Nagios e pelo servidor de backups. DNS Temos obrigatoriamente de adicionar o novo servidor ao servidor de DNS interno, presentemente na máquina corveta. Se o novo servidor vai oferecer serviços para fora do DI então precisará de ser adicionado também ao servidor de DNS externo, a máquina fragata. Nagios A máquina e respectivos serviços deverão ser adicionados ao Nagios para serem devidamente monitorizados, esta operação deverá ser feita apenas após haver alguma estabilidade na oferta destes mesmos serviços, se o serviço está a ser repetidamente reiniciado devido à execução de testes é perigoso estarmos a receber avisos do Nagios, pois poderão fazer com que não vejamos uma aviso realmente importante sobre outro serviço. Bacula 23

56 Capítulo 3. Outros Projectos 38 Por último teremos de configurar o sistema de backups para efectuar backups ao novo servidor. Deverão, no mínimo, ser feitos backups da directoria /etc, podendo/devendo serem feitos backups de outros dados que o justifiquem Switches Temos duas marcas de switches no nosso parque informático: HP e cisco, as configurações são semelhantes mas a forma de as conseguir podem diferir de marca para marca, se seguida dão-se instruções assumindo que estamos a configurar o switch da marca HP. Figura 3.4: Screenshot da interface web de um switch HP Existem duas maneiras de configurar o switch: consola e web, o interface web (Figura 3.4) é mais bonito e intuitivo mas omite as opções mais avançadas, por isso a melhor forma de configurar o switch é através de telnet (ou se estiver ligado na porta de série através do minicom 24 ). IP e DNS Em primeiro lugar há que arranjar um IP para o switch. Após essa operação adiciona-se esse IP ao DNS, o nome a escolher deverá seguir um critério diferente do utilizado até agora. Até aqui o nome seria: switch-edificio- 24