Instituto Politécnico de Viana do Castelo

Transcrição

1 Instituto Politécnico de Viana do Castelo Licenciatura Engenharia Electrónica e Redes de Computadores Administração de Sistemas e Dimensionamento de Redes Filipe Manuel de Faria Miranda (3568) 2006/2007

2

3 Instituto Politécnico de Viana do Castelo Departamento de Ciências Básicas e de Computação Administração de Sistemas e Dimensionamento de Redes Filipe Manuel de Faria Miranda (3568) Orientador ESTG: Eng.ª Sara Paiva Orientador IPVC: Eng.ª Maria Helena Moura Julho 2007

4

5 Dedico este trabalho à minha familia, em especial aos meus pais, irmão e amigos, que sempre me acompanharam ao longo destes anos.

6

7 Agradecimentos Quero agradecer em especial ao Pedro Sousa, administrador de sistemas do IPVC, pela sua boa recepção e pelo seu acompanhamento ao longo deste estágio. Sempre se mostrou disponível para esclarecer qualquer dúvida ou resolver qualquer problema. Ao Eng. José Neto pela sua disponibilidade demonstrada e apoio. Ao Dr. Carlos Rodrigues, Vice-Presidente do IPVC, à Eng. Sara Paiva orientadora do meu estágio na ESTG e aos restantes funcionários do IPVC, pela boa recepção nas instalações dos serviços centrais do IPVC. Ao meu colega de estágio, Pedro Barbosa, pelos momentos de boa disposição e pelo bom ambiente de trabalho proporcionado.

8

9 Resumo No âmbito do Estágio Curricular da Licenciatura em Engenharia Electrónica e Redes de Computadores, apresento este relatório no qual constam as actividades e trabalhos efectuados. Os trabalhos realizados incidentes na área de gestão e administração de sistemas, foram: Sistemas de Detecção de Intrusão (IDS-Intrusion Detection Systems), com uma ferramenta open source, o Snort. Monitorização de redes, com ferramentas open source, o Cacti, o MRTG e o Ntop. Implementação de um servidor de , o Postfix, usando Ldap (Lightweight Directory Access Protocol), com ferramentas open source. foram: Os trabalhos realizados incidentes na área de planeamento e dimensionamento de redes Planeamento e dimensionamento de estruturas de redes, no âmbito do projecto Valimar Digital; Actualização da documentação existente sobre a arquitectura da rede do IPVC. Palavras Chave (Tema): Segurança, fiabilidade, serviços, monitorização. Palavras Chave (Tecnologias): Linux, open source.

10

11 Conteúdo 1 Introdução Enquadramento Apresentação do estágio Apresentação da empresa Organização do relatório Contexto Valimar Digital Enquadramento Trabalho realizado Considerações finais Network Intrusion Detection System - Snort Enquadramento História do Snort Introdução Componentes do Snort Instalação e configuração Componentes necessários SSH Apache Instalação i

12 3.4.5 Regras Configuração Base de Dados Criação da base de dados Criação das tabelas Firewall Configuração BASE (Basic Analysis and Security Engine) Instalar o ADODB (Database Abstraction Library for PHP) Instalar o Base Configurar o Base Acesso ao Base Ntop Instalação e configuração Guardian Instalação e configuração Posicionamento do IDS na topologia da rede Configuração do Servidor de Rede Considerações finais Network Graphing Solution - Cacti Enquadramento Cacti Características Instalação Configuração Gráficos gerados Considerações finais ii

13 5 Multi Router Traffic Grapher - MRTG Enquadramento Introdução História da criação do MRTG Características e funcionalidades Instalação e configuração Autenticação Gráficos gerados Considerações finais Servidor de correio electrónico Postfix com Ldap Enquadramento Introdução LDAP NSSWITCH POSTFIX COURIER-POP/IMAP Implementação Configuração do OpenLDAP Configuração do NSSWITCH Configuração do POSTFIX Instalação e Configuração do COURIER IMAP Testes realizados Utilizadores LDAP SMTP e POP Considerações finais Outros trabalhos realizados Conclusões 103 iii

14 A MRTG 107 A.1 Ficheiro index.html A.2 Exemplo de um ficheiro de configuração B LDAP 115 B.1 Ficheiro ldap.con f B.2 Ficheiro slapd.con f B.3 Ficheiro nsswitch.con f C Postfix 123 C.1 Ficheiro main.c f D Valimar Digital 135 D.1 Exemplo da realização de um projecto iv

15 Lista de Figuras 3.1 Network Query Tool Base - Autenticação Base Ntop Topologia da rede Página inicial Página principal Configuração de um equipamento a monitorizar Configuração dos gráficos do equipamento a monitorizar Gráfico gerado Visualização dos gráficos por períodos de tempo Erro Página principal Pedido de Autenticação Erro de Autenticação Monitorização dos Serviços Centrais do IPVC Monitorização do Switch de Core do IPVC Gráficos detalhados da interface Gráficos detalhados da interface Exemplo de uma árvore (DIT) de um directório LDAP v

16 6.2 Estrutura LDAP utilizada Centro de Controlo Yast - Cliente LDAP Configuração do Cliente LDAP Configuração avançada - Definições do cliente Configuração avançada - Definições de administração Centro de Controlo Yast - Servidor LDAP Configuração do Servidor LDAP Configuração do Servidor - Definições Globais Testar utilizadores LDAP alterando o dono da pasta Diversos passos do teste ao SMTP Confirmação da recepção do Diversos passos do teste ao POP Estrutura da rede do IPVC vi

17 Notação e Glossário BASE Basic Analisys and Secure Engine DHCP Dynamic Host Configuration Protocol DNS Domain Name System FTP File Transfer Protocol GPL General Public License HTTP HyperText Transfer Protocol HTTPS HyperText Transfer Protocol Secure IDS Intrusion Detection System IMAP Internet Message Access Protocol IP Internet Protocol LAN Local Area Network LDAP Lightweight Directory Access Protocol MRTG Multi Router Traffic Grapher MTA Mail Transfer Agent NAT Network Address Translation NIDS Network Intrusion Detection System POP3 Post Office Protocol versão 3

18 RRD Round Robin Database SMTP Simple Mail Transfer Protocol SNMP Simple Network Management Protocol SQL Structed Query Language SSH Secure Shell ii

19 Capítulo 1 Introdução 1.1 Enquadramento O plano de estudos da Licenciatura em Engenharia Electrónica e Redes de Computadores consagra um período de 16 semanas (um semestre lectivo) que tem como objectivo integrar os alunos nas actividades produtivas e sociais das empresas, de forma a confrontarem o conhecimento teórico adquirido ao longo do curso com a realidade empresarial e industrial, facilitando assim a sua integração no mercado de trabalho. Com este estágio pretende-se: Aprender a trabalhar numa organização, aplicando os conhecimentos e técnicas aprendidos durante o curso; Aperfeiçoar os conhecimentos profissionais adquiridos durante o curso; Contactar com a realidade de uma empresa; Desenvolver espírito de equipa e atitudes de abertura à mudança. 1

20 2 CAPÍTULO 1. INTRODUÇÃO 1.2 Apresentação do estágio Com este estágio pretende-se fazer trabalhos na área de gestão/administração de sistemas e na área de planeamento e dimensionamento de estruturas de redes. Na área de gestão/administração de sistemas, pretende-se o estudo e desenvolvimento de ferramentas open source, que contribuirão para o suporte na administração dos sistemas e serviços no IPVC. Na área do planeamento e dimensionamento de estruturas de redes, pretende-se dimensionar e elaborar a documentação necessária para o planeamento da rede em fibra óptica, do projecto Valimar Digital. 1.3 Apresentação da empresa Este estágio foi realizado no Instituto Politécnico de Viana do Castelo. Criado em 1980 por Decreto-Lei, o IPVC encontra-se inserido no Alto Minho. O Instituto Politécnico de Viana do Castelo tem como objectivo prosseguir, através das suas Escolas, a formação humana, cultural, científica, técnica e profissional de qualidade, realizar a investigação necessária e adequada à prossecução da sua missão e cooperar com a comunidade regional, particularmente no seu tecido produtivo e empresarial, numa perspectiva de permanente diálogo e valorização recíproca. Na rede do Ensino Superior do Alto Minho, o Instituto Politécnico de Viana do Castelo é a entidade que dispõe de maior oferta formativa. Ministra 34 cursos superiores, entre os quais Bacharelatos, Licenciaturas e Licenciaturas bietápicas, Mestrados em cooperação com universidades estrangeiras e nacionais, cursos de Complemento de Formação e Profissionalização em Serviço e ainda cursos de Especialização, através das 5 Escolas Superiores que integra: Escola Superior de Educação (Viana do Castelo); Escola Superior Agrária (Ponte de Lima); Escola Superior de Tecnologia e Gestão (Viana do Castelo); Escola Superior de Enfermagem (Viana do Castelo);

21 1.4. ORGANIZAÇÃO DO RELATÓRIO 3 Escola Superior de Ciências Empresariais (Valença). A formação baseia-se numa forte aprendizagem interactiva com uma crescente utilização de estudos de casos reais, o que permite aos estudantes a melhor compreensão da realidade social e do funcionamento dos fenómenos culturais e sociais. A nível das estruturas físicas, o IPVC é detentor de um património histórico e arquitectónico considerável. As infra-estruturas de que dispõem as várias escolas variam entre estabelecimentos edificados em espaços seculares e de valor patrimonial e edifícios modernos, ambos os géneros apetrechados de sofisticado material tecnológico e equipamentos vários, de vanguarda, proporcionando um ensino em consonância com as exigências do mercado de trabalho, [13]. 1.4 Organização do relatório Neste Relatório possui 8 capítulos. No primeiro capítulo consta uma introdução. No segundo capítulo abordo um trabalho no âmbito do planeamento e dimensionamento de redes, neste caso em fibra óptica. Nos restantes capítulos apresentarei os trabalhos desenvolvidos no âmbito da administração e gestão de sistemas. Por fim num último capítulo apresento as minhas considerações finais. 1.5 Contexto Os avanços tecnológicos exercem hoje um grande impacto na sociedade. A informação tem-se tornado cada vez mais uma vantagem competitiva para as empresas e organizações em investimentos futuros. O facto é que, cada vez mais, as empresas, para se tornarem competitivas e sobreviverem no mercado, têm investido em tecnologia de informação, como a única forma de tornar seguro o processo decisório nas suas acções. E é nesse quadro que as redes de computadores se proliferam, encurtando as distâncias e diminuindo o tempo de resposta nas transacções entre as organizações de todo o mundo.

22 4 CAPÍTULO 1. INTRODUÇÃO Em decorrência das vantagens que as redes de computadores oferecem, o número e a extensão destas estão em expansão continua. À medida que as redes crescem em escala e extensão, dois factores vão ficando mais evidentes, as redes, juntamente com seus recursos e aplicações, tornamse cada vez mais indispensáveis para as organizações que as utilizam, e uma maior possibilidade de ocorrerem problemas, o que pode levar as redes a um estado de inoperância ou a níveis inaceitáveis de desempenho. A fim de garantir uma determinada qualidade de serviço aos seus utilizadores, as redes de computadores devem ser geridas e administradas de uma forma rigorosa e segura. Estas características envolve a monitorização e o controlo de recursos distribuídos em redes. Em essência, a administração de redes procura assegurar que sistemas de informação, disponíveis em redes, estejam operacionais e eficazes a todo instante, assegurando o bom funcionamento e desempenho das organizações.

23 Capítulo 2 Valimar Digital 2.1 Enquadramento A Comunidade Urbana Valimar (Valimar ComUrb) foi constituída a 11 de Março de 2004 pelos municípios de Arcos de Valdevez, Caminha, Esposende, Ponte da Barca, Ponte de Lima e Viana do Castelo. A paisagem verde dos vales e o azul do mar e do rio são o mote para a edificação de uma região una e coesa, tendo por denominador comum uma estrutura activa e dinâmica capaz de dar resposta a uma cooperação vantajosa entre as seis instituições autárquicas. Por isso, desde a sua constituição, a Valimar ComUrb tem pautado a sua acção pela continuidade do trabalho encetado pela extinta Associação de Municípios do Vale do Lima (Valima), mas tem igualmente apostado na união supra-municipal que está na sua base de acção. O projecto VALIMAR DIGITAL pode ser definido como um conjunto de sub-projectos, que se propõem contribuir para a criação de uma Região Digital reforçando o envolvimento do tecido social, institucional e empresarial na Sociedade da Informação. O conjunto dos sub-projectos do Valimar Digital, cada um de per si e na sua globalidade, visa, em termos gerais: -Generalizar o uso das TIC no funcionamento interno da Administração Local e na interacção desta com os cidadãos; -Promover as TIC como instrumento pedagógico ao serviço do desenvolvimento das crianças 5

24 6 CAPÍTULO 2. VALIMAR DIGITAL das Escolas; -Colocar as TIC ao serviço da generalização do saber, fomentando sinergias entre bibliotecas e arquivos; -Generalizar o uso das TIC no funcionamento das instituições de ensino superior e na relação que estas mantêm com os alunos, empresas e sociedade em geral; -Promover as TIC ao serviço da empresa flexível e competitiva, da comunidade urbana da Valimar; O IPVC, o Conselho Empresarial dos Vales de Lima e Minho (CEVAL) e a VALIMAR, constituíram, há três anos, um consórcio para a elaboração de um projecto e candidatura - o VALIMAR DIGITAL - visando a digitalização da região, com destaque para a componente do e-government Local, além de outros subprojectos importantes. O IPVC prestou o principal suporte à elaboração dessa candidatura, de grande complexidade técnica. A candidatura foi aprovada, nascendo agora um novo desafio que é o da sua execução, face à sua magnitude e ao curto espaço de tempo - fim de O IPVC assumirá, agora, as suas responsabilidades como parceiro e agente facilitador do desenvolvimento da região, cabendo-lhe a implementação do projecto no terreno e a central tecnológica de suporte, em fase já avançada de construção. Este projecto passa pela modernização das infraestruturas das Câmaras de modo a aproximá-las dos seus munícipes pelo uso das novas tecnologias. A Junta da Valimar (órgão constituído por todos os Presidentes das Câmaras) reuniu no IPVC, no passado dia 7 de Junho, onde o Presidente do IPVC, Professor Rui Teixeira e a restante equipa de docentes ligados ao projecto e técnicos, apresentaram detalhadamente o plano de implementação do projecto. A Junta da Valimar ComUrb esteve reunida no passado dia 07 de Junho no edifício dos serviços centrais do Instituto Politécnico de Viana do Castelo (IPVC) para analisar a evolução do e- Government local. Trata-se de uma iniciativa levada a efeito no âmbito do projecto Valimar Digital com vista à informatização autárquica, tendo como meta a melhoria da prestação dos serviços autárquicos aos municípes do espaço territorial da Valimar ComUrb, criando interacção entre o cidadão/utilizador/munícipe e os serviços. Foi ainda reforçado o papel decisivo do IPVC enquanto parceiro tecnológico do projecto, da

25 2.2. TRABALHO REALIZADO 7 Valimar ComUrb, e deste espaço territorial, ao colocar as competências que detém ao serviço do seu desenvolvimento. O e-government Local, recorde-se, implica a reformulação dos sítios Internet Municipais de forma a melhorar a qualidade dos serviços prestados ao cidadão ao nível do governo local, facilitar a comunicação entre o munícipe e a autarquia e reforçar a participação democrática; a concepção de um novo interface com a criação de serviços autárquicos on-line; e a disponibilização da intranet autárquica em banda larga para proporcionar um ambiente de trabalho homogéneo e capaz de potenciar os níveis de produtividade e eficácia na acção autárquica. Os seis municípios que integram a comunidade urbana Valimar vão ficar ligados em banda larga através de uma rede de fibra óptica com mais de 126 quilómetros de extensão, num investimento de 10 milhões de euros. A Valimar adianta que, uma vez implementado, o projecto vai aumentar a atractividade das empresas e dos serviços de base tecnológica, uma vez que a infra-estruturação desta rede, composta por 24 pares de fibra óptica, passará pela utilização livre de acesso aos operadores de serviços acreditados pela Autoridade Nacional de Comunicações (Anacom), [14]. 2.2 Trabalho realizado A nossa participação no projecto Valimar Digital consistiu no levantamento, no terreno, das infra-estruturas a serem utilizadas na passagem da fibra óptica e na elaboração dos documentos técnicos a serem entregues a cada município. O levantamento, no terreno, das infra-estruturas é uma acção crucial no desenvolvimento de todo o projecto referente a cada município. O levantamento no terreno consistiu na observação dos possíveis locais de passagem da fibra: condutas de águas pluviais, condutas existentes e condutas existentes pertencentes á Portugal Telecom. Na ausência destas era necessário definir um trajecto para posteriormente ser construído. Foram observadas minuciosamente todas as condutas pluviais (levantando todas as tampas de águas pluviais e observando o seu interior) de forma a certificarmo-nos que não havia im-

26 8 CAPÍTULO 2. VALIMAR DIGITAL pedimentos para a passagem da fibra óptica. Mesmo que os técnicos municipais afirmassem com muitas certezas que alguns pontos estavam em perfeitas condições e seguiam determinada direcção, nenhuma tampa deixou de ser levantada pois não poderíamos correr o risco de não haver continuidade entre esse ponto e a tampa seguinte. Também os edifícios a interligar foram alvo de uma visita com o intuito de saber onde iriam ser instalados os racks de fibra óptica e que obras interiores seriam necessárias realizar. Ao mesmo tempo que averiguávamos as infra-estruturas, era desenhado e anotado, em mapas fornecidos pela autarquia, o percurso, as distâncias entre cada tampa, de que tipo de conduta se tratava (pluvial, existente, da PT ou a construir) e a designação de cada tampa. Foram fotografados todos os edifícios (exterior e interior), tampas e caixas pertencentes ao troço. Numa segunda fase, na elaboração dos documentos, foi feita a compilação de toda a informação que obtivemos com o estudo no terreno. Desenhamos, no Visio, todo o percurso por onde passará a fibra óptica, assinalando todas as tampas, a sua designação e o local de início e fim de troço. Tudo isto era desenhado seguindo certas regras de cores e designações que passamos a explicar: O bastidor do edifício de onde sai a fibra (local de inicio de troço) é representado por um rectângulo preenchido a cor azul e com contornos laranja; O bastidor do edifício de chegada da fibra (local de fim do troço) é representado por um rectângulo preenchido a cor amarela e com contornos laranja; Uma splice box (caixa de fusão) é representada por um quadrado com contornos vermelhos e com dois triângulos preenchidos a verde fluorescente voltados um para o outro no seu interior. É designado por SP precedido da designação do município (exemplo: PDL para a câmara de Ponte de Lima ou ESP para Esposende) e o número sequencial correspondente (exemplo: ESP-SP3); O trajecto efectuado pela fibra dentro dos edifícios é representado por uma linha tracejada de cor violeta; O trajecto no exterior que é feito em condutas de águas pluviais é representado por uma linha verde;

27 2.2. TRABALHO REALIZADO 9 O trajecto no exterior que é feito em condutas existentes é representado por uma linha laranja; O trajecto no exterior que é feito em condutas da Portugal Telecom é representado por uma linha azul; O trajecto no exterior que irá ser feito em condutas a construir é representado por uma linha violeta; As tampas das condutas de águas pluviais são representadas por círculos ou elipses com contornos verdes. A sua designação é CVPAP mais a designação do município mais um número sequencial (exemplo: CVPAP-ESP67); As tampas das condutas existentes são representadas por rectângulos com contornos laranja. A sua designação é CVPFO mais a designação do município mais um número sequencial (exemplo: CVPFO-PDL65); As tampas das condutas da Portugal Telecom são representadas por rectângulos com contornos azuis. A sua designação é CVPPT mais a designação do município mais um número sequencial (exemplo: CVPPT-PDL13); As tampas das condutas a construir são representadas por rectângulos com contornos violeta. A sua designação é CVPFO mais a designação do município mais um número sequencial (exemplo: CVPFO-ESP22); Para além do mapa, o documento contém as tabelas de comprimento de cabos, de controlo de Caixas de Visita (CVP) e de controlo e/ou levantamento de construção de valas. A tabela de comprimento de cabos contém informação ponto a ponto do comprimento da folga de cabos, da quantidade de metros de cabo que passarão em condutas pluviais, da PT, existentes ou a construir, assim como o comprimento de cabo dentro dos edifícios. Tudo isto somado dá-nos o comprimento total do cabo. A tabela de controlo de Caixas de Visita dá-nos a indicação do tipo de caixa (Telecom-tipo1 ou 2 ou existente), a identificação do cabo e se é necessário construir ou se é uma caixa existente. Por fim a tabela de controlo e/ou levantamento de construção de valas

28 10 CAPÍTULO 2. VALIMAR DIGITAL diz-nos as medidas das valas quer a construir quer as já existentes. Faz parte do documento um relatório fotográfico onde podemos visualizar todas as caixas, tampas e sua designação, direcção da próxima tampa ou caixa, local de instalação dos racks, etc. Ou seja, com o relatório fotográfico é possível a alguém que desconheça o local, executar o projecto sem dificuldades. Toda a informação importante e necessária para a instalação da fibra está inserida no relatório fotográfico. O documento contempla ainda informações como: instalação dos cabos em conduta, instalação do cabo em condutas de águas ou em esgotos, instalação do cabo de fibra óptica em caixa de visita permanente (CVP), legislação aplicável, preparação do cabo e fusão da fibra óptica, configuração típica de um rack de transmissão óptica, descritivo do mapa de alocação das fibras e mapa de ligação das fibras ópticas. Pode ser consultado em anexo a este relatório, um exemplo de um desses documentos. 2.3 Considerações finais A minha participação no projecto Valimar Digital, contribui para um grande enriquecimento do meu conhecimento na área de planeamento e dimensionamento de redes. Adquiri conhecimentos sobre os processos de dimensionamento de uma rede em fibra óptica, aperfeiçoando os conceitos teóricos adquiridos ao longo do curso sobre esta matéria. O relacionamento com pessoas envolvidas neste projecto foi excelente e muito gratificante, sempre dispostas a esclarecer qualquer dúvida. Sendo estas, experientes e muito profissionais nesta área, contribuíram em muito, para a minha formação e aprendizagem nesta matéria. Sendo um projecto com uma grande dimensão, envolvendo inúmeras organizações de grande prestígio, foi para mim uma grande honra ter participado nesta experiência.

29 Capítulo 3 Network Intrusion Detection System - Snort 3.1 Enquadramento Nos últimos anos, tem-se sentido um aumento de incidentes de segurança informática, isto é o reflexo do crescimento exponencial da Internet, e aumento da utilização das redes de computadores e serviços por elas suportados. Os sistemas de detecção de intrusão têm sido utilizados para protecção, monitorização de actividades maliciosas e diversos tipos de ataques. Com o objectivo de dotar o centro de comunicações do IPVC (Data Center) com este sistema, foi proposto o estudo e a implementação de um sistema de detecção de intrusão usando a ferramenta Snort. O Snort foi a ferramenta de eleição para tal desenvolvimento, tendo esta uma enorme popularidade nesta area e sendo Open Source. Um IDS de rede, de uma forma muito básica, é um sniffer de rede que compara o conteúdo da informação dos pacotes que passam no meio, com uma base de dados de assinaturas e/ou anomalias que indicam potencial actividade maliciosa. 11

30 12 CAPÍTULO 3. NETWORK INTRUSION DETECTION SYSTEM - SNORT 3.2 História do Snort O Snort foi desenvolvido em linguagem de programação C baseando-se na biblioteca de programação libpcap (biblioteca para captura de pacotes de rede), que é utilizada em ferramentas de captura de tráfego de rede, tais como os sniffers (p.e. Ethereal). Inicialmente, o criador do Snort, Marty Roesch, queria construir uma ferramenta de sniffing para ambiente Linux melhor do que as existentes no mercado, tal como o popular tcpdump, ferramenta nativa de sistemas baseados em Unix, utilizado para captura de pacotes. Depois de concluir o objectivo de capturar pacotes, Marty começou a desenvolver o Snort para desempenhar as funções de IDS, pois não existiam softwares livres e eficientes que desempenhassem esta função. Em 1999 consegue atingir o objectivo de habilitar o Snort a comparar o tráfego de rede com as regras que ele definiu. Neste mesmo ano, a comunidade científica de open source começou a testar o Snort permitindo assim que este fosse alvo de diversas actualizações, o que o tornou mais fácil de configurar e adaptar para utilização em ambientes organizacionais, [2]. 3.3 Introdução O Snort é uma ferramenta open source para soluções NIDS- Network Intrusion Detection System. O logótipo do Snort é um porco, em alusão à tarefa de farejar e capturar todos os pacotes que estão a passar na rede. Uma vez que o Snort tem a capacidade de analisar todo o conteúdo dos pacotes, comparando-o com um vasto conjunto de regras em tempo real, tornou-o desde o seu aparecimento, um IDS de eleição. O facto de ser disponibilizado em open source permite que as pessoas fortemente interessadas em aplicar um NIDS na sua rede o possam testar sem qualquer preocupação de adquirir ou comprar licenças de softwares proprietários. Tal facto permitiu ainda, que ao longo do tempo fosse sofrendo bastantes actualizações e correcções como ainda hoje acontece frequentemente, possibilitando também que os utilizadores possam desenvolver as suas próprias regras para detecção

31 3.3. INTRODUÇÃO 13 de ataques existindo sempre um espírito de partilha das mesmas. É sem dúvida o sistema de detecção de intrusão open source com maior popularidade e utilização Componentes do Snort O Snort encontra-se dividido em vários componentes. Esses componentes trabalham em conjunto para detectar ataques e gerar outputs num determinado formato. Um sistema baseado no IDS Snort é composto pelos seguintes principais componentes: Packet Decoder Prepara os pacotes para serem processados. O packet decoder apanha os pacotes provenientes de diferentes tipos de interfaces de rede, e prepara-os para serem pré-processados ou envia-os para o motor de detecção. Preprocessors É utilizado para normalizar os cabeçalhos dos protocolos, detectam anomalias na construção dos pacotes. São componentes ou plug-ins que podem ser usados com o Snort para reconstruir ou modificar dados dos pacotes antes do motor de detecção realizar alguma operação, verifica se um pacote está a ser utilizado por um invasor. Alguns pré-processadores também realizam detecção de anomalias encontradas em cabeçalhos de pacotes. São componentes muito importantes para qualquer IDS, prepara os dados dos pacotes para serem analisados, comparando-os com as regras do motor de detecção. Muitos atacantes utilizam fragmentação de pacotes para enganar IDSs, os pré-processadores no Snort fazem desfragmentação de pacotes, descodificam HTTP, etc. Detection Engine O motor de detecção é um dos componentes mais importantes do Snort. É responsável por detectar actividades de intrusão existentes num pacote. O motor de detecção emprega regras Snort para este propósito. As regras são lidas em estruturas, ou cadeias de dados internas, onde é verificado se existe correspondência com os pacotes. Caso um pacote corresponda a alguma

32 14 CAPÍTULO 3. NETWORK INTRUSION DETECTION SYSTEM - SNORT regra, acções apropriadas são tomadas, caso contrário o pacote é rejeitado. Acções apropriadas poderão ser, gerar alertas ou fazer logging do pacote. Logging and Alert System Dependendo do que o motor de detecção encontra dentro do pacote, este poderá ser utilizado para registar (logging) a actividade ou gerar um alerta. Os logs são mantidos em simples ficheiros de texto, ficheiros do tipo tcpdump ou outros formatos disponíveis. Output Modules Processamento de alertas e logs, gera um output final. Basicamente estes módulos controlam o tipo de output gerado a partir de alertas e logging. É possível fazer simplesmente logging para um ficheiro de alertas, envio para syslog, utilizar uma base dados MYSQL ou Oracle, etc. [16], [17]. 3.4 Instalação e configuração Componentes necessários Para a instalação e bom funcionamento do Snort é necessário instalar alguns componentes, bibliotecas, etc. Para instalar esses componentes necessários, executamos o comando yum com os seguintes parâmetros: #yum -y install mysql mysql-bench mysql-server mysql-devel mysqlclient10 php-mysql httpd gcc pcre-devel php-gd gd mod_ssl glib2-devel gcc-c SSH SSH - Protocolo de rede que permite a ligação a um computador na rede, por forma a poder executar comandos á partir de uma maquina remota.

33 3.4. INSTALAÇÃO E CONFIGURAÇÃO 15 No caso de pretendermos configurar a maquina remotamente por SSH, é necessário proceder a umas pequenas alterações no ficheiro de configuração. Para tal abrimos o ficheiro sshd con f ig que se encontra na localização: /etc/ssh/ e alteramos os seguintes parâmetros: Protocol 2 PermitRootLogin no PermitEmptyPasswords no Guardar o ficheiro e reiniciar o serviço sshd : #Service sshd restart Iniciar os serviços necessários no arranque: #chkconfig httpd on #chkconfig mysqld on #service httpd start #service mysqld start Apache A partir da localização: /var/www/html, digitar o seguinte comando: #wget De seguida copiar o conteúdo do ficheiro index.php.tex para o ficheiro index.php. Assim ao digitar irá ser apresentado uma pequena aplicação (como mostra a figura 5.1), para testar o bom funcionamento do Apache Instalação Criar uma directoria para colocar os ficheiros de instalação: #cd /root #mkdir snortinstall

34 16 CAPÍTULO 3. NETWORK INTRUSION DETECTION SYSTEM - SNORT Figura 3.1: Network Query Tool

35 3.4. INSTALAÇÃO E CONFIGURAÇÃO 17 A partir dessa localização, fazer o download do snort, e proceder a sua instalação: #wget #tar -xvzf snort tar.gz #cd snort #./configure --with-mysql --enable-dynamicplugin #make #make install #groupadd snort #useradd -g snort snort s /sbin/nologin #mkdir /etc/snort #mkdir /etc/snort/snortrules #mkdir /var/log/snort #cd etc/ #cp * /etc/snort

36 18 CAPÍTULO 3. NETWORK INTRUSION DETECTION SYSTEM - SNORT Regras A partir da localização /root/snortinstall: #wget snortrules-pr-2.4.tar.gz #tar xvzf snortrules-pr-2.4.tar.gz #cp * /etc/snort/rules Configuração O ficheiro de configuração do snort snort.conf, encontra-se na localização /etc/snort/. Vamos proceder a alteração de algumas configurações. Definir a rede interna: var HOME_NET /24 Tudo o que não seja HOME NET (rede interna) é designado como EXT ERNAL NET : var EXTERNAL_NET!$HOME_NET Alterar a linha onde consta o caminho da localização das regras para: var RULE_PATH /etc/snort/rules A seguir a linha: preprocessor stream4 reassemble, adicionar a seguinte linha: preprocessor stream4_reassemble: both,ports Na secção output section do ficheiro de configuração alteramos a seguinte linha para o Snort poder escrever na base de dados.

37 3.5. BASE DE DADOS 19 output database: log, mysql, user=snort password=<the password you gave it> dbname=snort host=localhost De seguida vamos fazer com que o Snort arranque com o sistema. Vamos para a localização /etc/init.d e executamos os seguintes comandos: #wget #chmod 755 snort #chkconfig snort on #service snort start 3.5 Base de Dados Criação da base de dados Para a criação da base de dados: mysql mysql> SET PASSWORD FOR root@localhost=password( password ); >Query OK, 0 rows affected (0.25 sec) mysql> create database snort; >Query OK, 1 row affected (0.01 sec) mysql> grant INSERT,SELECT on root.* to snort@localhost; >Query OK, 0 rows affected (0.02 sec) mysql> SET PASSWORD FOR snort@localhost=password( password_from_snort.conf ); >Query OK, 0 rows affected (0.25 sec) mysql> grant CREATE, INSERT, SELECT, DELETE, UPDATE on snort.* to snort@localhost; >Query OK, 0 rows affected (0.02 sec)

38 20 CAPÍTULO 3. NETWORK INTRUSION DETECTION SYSTEM - SNORT mysql> grant CREATE, INSERT, SELECT, DELETE, UPDATE on snort.* to snort; >Query OK, 0 rows affected (0.02 sec) mysql> exit >Bye Criação das tabelas Para a criação das tabelas: #mysql -u root -p < /snortinstall/snort-2.6.0/schemas/create_mysql snort #Enter password: password do mysql definida anteriormente Verificar se a base de dados foi bem criada: #mysql -p >Enter password: mysql> SHOW DATABASES; Deve ser apresentado o seguinte: Database mysql Snort test rows in set (0.00 sec) mysql> use snort >Database changed mysql> SHOW TABLES;

39 3.6. FIREWALL 21 Tables_in_snort data detail encoding event icmphdr iphdr opt reference reference_system schema sensor sig_class sig_reference signature tcphdr udphdr rows in set (0.00 sec) exit; 3.6 Firewall Configuração Ir para /etc/syscon f ig/, e editar o ficheiro de firewall. Adicionar a seguinte linha: -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT

40 22 CAPÍTULO 3. NETWORK INTRUSION DETECTION SYSTEM - SNORT E apagar as seguintes: -A RH-Firewall-1-INPUT -p 50 -j ACCEPT -A RH-Firewall-1-INPUT -p 51 -j ACCEPT -A RH-Firewall-1-INPUT -p udp --dport d j ACCEPT -A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT Alterar a seguinte: -A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT Para: -A RH-Firewall-1-INPUT -p icmp --icmp-type any -j DROP Assim só será possível aceder a maquina por https. Reiniciar o service de iptables: service iptables restart 3.7 BASE (Basic Analysis and Security Engine) O Base (Basic Analysis and Security Engine) foi desenhado para ajudar profissionais de segurança a gerir alertas provenientes de múltiplos sensores IDS Snort. É o sucessor do conhecido ACID.É uma interface de gestão utilizado pelo CERT.PT desde Novembro de 2006, com excelentes resultados. Neste momento é a ferramenta com maior maturidade e desenvolvimento para analisar alertas geradas pelo Snort. Usando o BASE com o Snort Intrusion Detection System é possível visualizar todas as entradas e tentativas de entradas no sistema, através de consola web, [5]. Vamos começar por fazer o download do Base e do ADODB, para tal vamos a directoria /root/snortinstall, e executamos:

41 3.7. BASE (BASIC ANALYSIS AND SECURITY ENGINE) 23 #wget_http://easynews.dl.sourceforge.net/sourceforge/adodb/adodb480.tgz #wget_http://easynews.dl.sourceforge.net/sourceforge/secureideas/base tar.gz Para os gráficos, executar: #pear install Image_Graph-alpha Image_Canvas-alpha Image_Color Numbers_Roman Instalar o ADODB (Database Abstraction Library for PHP) #cd /var/www/ #tar -xvzf /root/snortinstall/adodb480.tgz Instalar o Base #cd /var/www/html #tar xvzf /root/snortinstall/base tar.gz #mv base-1.2.6/ base/ (muda o nome da directoria base para base) Copiar o ficheiro base conf.php.dist para o base conf.php Configurar o Base Editar o ficheiro de configuração do Base base conf.php e inserir os seguintes parâmetros: $BASE_urlpath = "/base"; $DBlib_path = "/var/www/adodb/ "; $DBtype = "mysql"; $alert_dbname = "snort"; $alert_host = "localhost"; $alert_port = ""; $alert_user = "snort"; $alert_password = "password_from_snort_conf"; $archive_exists = 0;

42 24 CAPÍTULO 3. NETWORK INTRUSION DETECTION SYSTEM - SNORT Abrir o browser, address/base/ Acesso ao Base Para tornar o acesso ao Base seguro, irá ser pedido ao utilizador que insira as suas credenciais para poder visualizar os dados (ver figura 5.2). #mkdir /var/www/passwords #/usr/bin/htpasswd -c /var/www/passwords/passwords base Editar o ficheiro httpd.conf, /etc/htt pd/con f : <Directory "/var/www/html/base"> AuthType Basic AuthName "SnortIDS" AuthUserFile /var/www/passwords/passwords Require user base </Directory> Reiniciar o servidor Apache: #service httpd restart 3.8 Ntop O Ntop - Network Traffic Probe - é um aplicativo capaz de mostrar a utilização da rede por host, protocolo, etc. O Ntop possui uma interface web e é capaz de gerar gráficos que facilita a interpretação de estatísticas em tempo real Instalação e configuração Na localização /etc/yum.repos.d criar um ficheiro com o nome dag.repo, onde colocamos o seguinte texto:

43 3.8. NTOP 25 Figura 3.2: Base - Autenticação

44 26 CAPÍTULO 3. NETWORK INTRUSION DETECTION SYSTEM - SNORT Figura 3.3: Base

45 3.8. NTOP 27 [dag] name=dag RPM Repository for Red Hat Enterprise Linux baseurl= gpgcheck=1 enabled=1 Importar uma chave GPG: #rpm --import Instalar o Ntop: #yum install ntop Editar o ficheiro de configurações do Ntop ntop.conf, que se encontra na localização /etc/ntop.con f, e efectuar as seguintes alterações: --interface eth1 (Interface a usar) --https-server 3001 to --https-server 3001 (activar SSL na porta 3001) --daemon (Ntop como daemon) Adicionar uma entrada no iptables para a porta 3001, para tal ir para /etc/syscon f ig/iptables, -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport j ACCEPT Reiniciar o serviço de iptables: #service iptables restart Vamos agora definir uma password para o Administrador do Ntop:

46 28 CAPÍTULO 3. NETWORK INTRUSION DETECTION SYSTEM - SNORT -A Ntop a iniciar-se com o sistema: #chkconfig ntop on #service ntop start Abrir o browser, address:3001, como mostra a figura Guardian O Guardian é um programa que funciona em conjunto com o Snort. A sua função consiste na actualização automática das regras do iptables, com base nas alertas geradas pelo Snort. A actuação conjunta do Snort e do Guardian torna possível dotar o Snort de mecanismos de reacção em caso de intrusão e prevenção de ataques futuros. De seguida são apresentados os passos para instalação deste programa Instalação e configuração Efectuar o download do Guardian em Executar os seguintes comandos: #mv guardian-x-x.tar.gz /usr/src #tar -xvzf guardian-x-x.tar.gz #cd guardian-x-x #cd scripts #ls A directoria scripts deverá ter os seguintes scripts:

47 3.9. GUARDIAN 29 Figura 3.4: Ntop

48 30 CAPÍTULO 3. NETWORK INTRUSION DETECTION SYSTEM - SNORT freebsd_block.sh freebsd_unblock.sh ipchain_block.sh ipchain_unblock.sh iptables_block.sh iptables_unblock.sh O Guardian utiliza sempre os scripts denominados guardian block.sh e guardian unblock.sh. Assim, deverão ser copiados para ficheiros com esses nomes os correspondentes ao filtro de pacotes que pretendemos utilizar. No caso concreto do iptables que é o mais frequentemente utilizado, deverão realizar-se os seguintes comandos: #cp iptables_block.sh /usr/bin/guardian_block.sh #cp iptables_unblock.sh /usr/bin/guardian_unblock.sh #chmod 755 /usr/bin/guardian_block.sh /usr/bin/guardian_unblock.sh Copiar o script e ficheiro de configuração do Guardian para os locais correspondentes, através dos seguintes comandos: #cd.. #cp guardian.pl /usr/bin #chmod 755 /usr/bin/guardian.pl #cp guardian.conf /etc/ /etc/: Configurar os seguintes parâmetros no ficheiro guardian.con f que se encontra na localização Interface eth0 (interface eth0, a que vai ter os terminais bloqueados)

49 3.10. POSICIONAMENTO DO IDS NA TOPOLOGIA DA REDE 31 AlertFile /var/adm/secure (mudar para /var/log/snort/alert) TimeLimit (mudar para um valor em segundos que pretendemos que o endereço IP fique bloqueado pela firewall.) Criar o arquivo de log do Guardian, através do comando: #touch /var/log/guardian.log Criar o ficheiro guardian.ignore com os endereços IP que se pretende ignorar: #touch /etc/guardian.ignore Iniciar o Guardian: #guardian.pl -c /etc/guardian.conf OS shows Linux Warning! HostIpAddr is undefined! Attempting to guess.. Got it.. your HostIpAddr is My ip address and interface are: eth0 Loaded 3 addresses from /etc/guardian.ignore Becoming a daemon Posicionamento do IDS na topologia da rede Um IDS (Intrusion Detection System) tornou-se para muitos profissionais de segurança o segundo produto a adquirir, logo seguido da firewall. Uma firewall é utilizada para prevenção, um IDS para detecção. A topologia de rede, na qual foram instaladas e configuradas as ferramentas mencionadas e descritas anteriormente, se encontra na figura 5.6. O servidor de rede e o IDS foram instalados e configurados na mesma máquina.

50 32 CAPÍTULO 3. NETWORK INTRUSION DETECTION SYSTEM - SNORT Figura 3.5: Topologia da rede

51 3.10. POSICIONAMENTO DO IDS NA TOPOLOGIA DA REDE Configuração do Servidor de Rede Para garantir o bom funcionamento da rede interna, foi necessário configurar algumas ferramentas e serviços. NAT O NAT-Network Address Translation, surgiu como uma alternativa real para o problema de falta de endereços IP v4 na Internet. Cada computador que acede a Internet deve ter o protocolo TCP/IP correctamente instalado e configurado. Para isso, cada computador da rede interna, precisaria de um endereço IP válido na Internet. Não haveria endereços IP v4 suficientes. A criação do NAT veio para solucionar esta questão. Com o uso do NAT, os computadores da rede Interna, utilizam os chamados endereços Privados. Os endereços privados não são válidos na Internet, isto é, pacotes que tenham como origem ou como destino, um endereço na faixa dos endereços privados, não serão encaminhados, serão descartados pelos routers. O software dos routers está configurado para descartar pacotes com origem ou destino dentro das faixas de endereços IP privados. As faixas de endereços privados são definidas na RFC 1597 e estão indicados a seguir: > > > Por exemplo, uma rede com 100 computadores, usando um esquema de endereçamento / , poderá ter acesso à Internet, usando o NAT, usando um único endereço IP válido: o endereço IP da interface externa do NAT. Por estas razões, foi necessário configurar o nosso servidor para fazer NAT. Para isso, vamos mascarar todos os pacotes provenientes da nossa rede interna ( /24), destinados a Internet, com o IP Publico ( /24). Isso é feito na chain POSTROUTING, logo antes de que o pacote saia da máquina, [1]. Para tal executamos o comando:

52 34 CAPÍTULO 3. NETWORK INTRUSION DETECTION SYSTEM - SNORT #iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE E reiniciamos os serviços de rede: #service network restart DHCP O DHCP, Dynamic Host Configuration Protocol, é um protocolo de serviço TCP/IP que oferece configuração dinâmica de terminais, com concessão de endereços IP de host e outros parâmetros de configuração para clientes de rede. Para tal, configuramos o nosso ficheiro dhcpd.con f que se encontra em /etc/, da seguinte forma: ddns-update-style interim; ignore client-updates; #REDE A QUAL SE APLICA: subnet netmask { #DEFAULT GATEWAY: option routers ; option subnet-mask ; #DOMINIO E SERVIDORES DNS: option nis-domain "ipvc.pt"; option domain-name "ipvc.pt"; option domain-name-servers ; option time-offset ;

53 3.11. CONSIDERAÇÕES FINAIS 35 range dynamic-bootp ; default-lease-time 21600; max-lease-time 43200; # we want the nameserver to appear at a fixed address host ns { next-server marvin.redhat.com; hardware ethernet 12:34:56:78:AB:CD; fixed-address ; } } 3.11 Considerações finais A instalação e configuração desta ferramenta foi executado numa máquina virtual, podendo assim, serem realizados todos os testes de desempenho e possíveis cenários de ataques, sem comprometer o bom funcionamento da Instituição. Através desta ferramenta e de outras, envolvidas no processo de instalação e configuração, aperfeiçoei e adquiri novos conhecimentos. Este trabalho envolveu vários conceitos de redes e contribuiu para alargar o meu conhecimento sobre o sistema operativo Linux, em particular na distribuição CentOS, na qual assenta este trabalho. Todos os objectivos traçados para este trabalho foram alcançados com sucesso, encorajando assim a implementação desta ferramenta no Data Center do IPVC, para garantir uma maior segurança aos seus utilizadores.

54 36 CAPÍTULO 3. NETWORK INTRUSION DETECTION SYSTEM - SNORT

55 Capítulo 4 Network Graphing Solution - Cacti 4.1 Enquadramento Com o crescimento constante e evolução das redes de computadores, têm se tornado fundamental a área de gestão de redes agregar as necessidades de monitorização e controlo. Assim, podemos dizer que é muito importante dentro de uma organização a implementação de uma ferramenta de monitorização para controlar a rede evitando assim ocorrer riscos de falhas, devidos a sobrecargas na rede. Foi proposto a implementação de uma ferramenta de monitorização para as instalações do IPVC. Com o objectivo claro de poder controlar o estado do tráfego em cada instituição, em cada escola. Para tal foi proposto o estudo e teste de duas ferramentas: o Cacti e o MRTG. Para determinar qual destas se adequava melhor aos objectivos traçados, foram efectuados testes em maquinas virtuais, para analisar os seus comportamentos. Começamos por implementar e testar o Cacti. 4.2 Cacti O Cacti é uma ferramenta gráfica de gestão de dados de rede desenvolvida para ser utilizada por administradores de rede sem relevante experiência mas que disponibiliza recursos bem poderosos para serem utilizados em redes bastante complexas. O Cacti é um front-end para o RRDTOOL 37

56 38 CAPÍTULO 4. NETWORK GRAPHING SOLUTION - CACTI desenvolvido na linguagem PHP. Possui uma interface web e armazena todos os dados numa base de dados MySql. Utilizando esta ferramenta, é possível fazer o polling de hosts SNMP, criar gráficos e gerir o acesso de utilizadores a toda a informação já recolhida. RRD é a abreviatura de Round Robin Database, sistema cujo objectivo é armazenar e monitorizar dados em série obtidos durante um período de tempo pré determinado. Estes dados não aumentam nem com o decorrer do tempo, nem com a quantidade de dados já armazenados. Entretanto, o RRDTOOL não é capaz de gerar páginas html ou produzir gráficos, facto que torna necessário a sua utilização associada a um front-end, [9] Características Esta ferramenta disponibiliza aos seus utilizadores uma interface agradável e fácil de usar. Com o Cacti, é possível fazer o controlo de acesso por nível de utilizador, ou seja, podemos configurar o acesso a certas informações apenas para determinados utilizadores. O CACTI é um programa open source, ou seja, está disponível para qualquer utilizador fazer o seu download e instalá-lo no computador. 4.3 Instalação O Cacti exige que se tenha instalado em seu computador os seguintes pacotes: Apache (ou outro servidor web) PHP (versão > 4) + extensões php-snmp e php-gd2 Base de dados MySQL net-snmp RRDtool Download da ultima versão estável do cacti 0.8.6i, em: cacti.php

57 4.3. INSTALAÇÃO 39 Primeiramente é necessário instalar todos os compiladores requeridos, através dos seguinte comandos: #yum install apache2 #yum install php5 #yum install mysql-server #yum install rrdtool Depois de fazer o download do Cacti, executamos em /var/www: #tar xzvf cacti-version.tar.gz #mv cacti-version.tar.gz cacti Criação da base de dados do Cacti no MySQL: #mysqladmin --user=root create cacti Importar a base de dados default do Cacti: #mysql cacti < cacti.sql Criar no MySQL um utilizador e uma palavra-chave para Cacti: #mysql --user=root mysql mysql> GRANT ALL ON cacti.* TO cactiuser@localhost IDENTIFIED BY palavra-chave ; mysql> flush privileges; Editamos as linhas abaixo no ficheiro /www/var/cacti/include/con f ig.php especificamos o utilizador MySQL, palavra-chave e a base de dados de configuração do Cacti: $database_default = "cacti"; $database_hostname = "localhost"; $database_username = "cactiuser"; $database_password = "cacti";

58 40 CAPÍTULO 4. NETWORK GRAPHING SOLUTION - CACTI Vamos dar permissões ao utilizador cacti nos directórios do Cacti para a geração dos gráficos e registros: # chown -R cactiuser rra/ log/ Adicionamos a linha abaixo no ficheiro /etc/crontab: */5 * * * * cactiuser php /var/www/cacti/poller.php > /dev/null 2>&1 Finalmente, para visualizar a interface web digite: Configuração Ao digitar aparece uma janela inicial como mostra a figura 4.1. Após inserir as credenciais, UserName : admin e Password : teste, é apresentada a página principal do Cacti, como mostra a figura 4.2. O Cacti dá-nos a possibilidade de poder personalizar cada gráfico: mudar as cores dos gráficos, cores de áreas específicas, largura e altura dos gráficos, escala, entre outras características. O Cacti permite-nos definir configurações personalizadas para cada utilizador, permitindo que este apenas visualize o que realmente o interessa. É possível criar novos utilizadores e alterar permissões de utilizadores já existentes. Para adicionar um novo utilizador, basta clicar em ADD e definir as configurações que desejar. Para verificar ou alterar algumas configurações do cacti, clique na opção Settings presente no canto esquerdo da janela no menu Configuration: A figura 4.3, mostra-nos a página de criação e configuração de um novo equipamento a monitorizar. A figura 4.4, mostra-nos a página de configuração dos gráficos do equipamento a monitorizar.

59 4.4. CONFIGURAÇÃO 41 Figura 4.1: Página inicial

60 42 CAPÍTULO 4. NETWORK GRAPHING SOLUTION - CACTI Figura 4.2: Página principal

61 4.4. CONFIGURAÇÃO 43 Figura 4.3: Configuração de um equipamento a monitorizar

62 44 CAPÍTULO 4. NETWORK GRAPHING SOLUTION - CACTI Figura 4.4: Configuração dos gráficos do equipamento a monitorizar

63 4.5. GRÁFICOS GERADOS Gráficos gerados Através das figuras 4.5 e 4.6, podemos visualizar alguns exemplos de gráficos gerados pelo Cacti. Este permite a visualização diária, semanal, mensal e anual das estatísticas geradas nos gráficos. Os gráficos sao apresentados de uma forma muito agradável, possibilita também a opção de fazer zoom a uma determinada area do gráfico gerado. Figura 4.5: Gráfico gerado

64 46 CAPÍTULO 4. NETWORK GRAPHING SOLUTION - CACTI Figura 4.6: Visualização dos gráficos por períodos de tempo

65 4.6. CONSIDERAÇÕES FINAIS Considerações finais Após analisar o comportamento desta ferramenta, testando o seu desempenho e explorando a sua configuração, foi concluído que esta oferece um bom desempenho e disponibiliza ao utilizador um ambiente de configuração bastante elaborado. Durante a fase de instalação surgiram algumas dificuldades, devido à erros relativos a falta de bibliotecas necessárias para o bom funcionamento da ferramenta. Ultrapassadas estas, deparámo-nos com um ambiente de configuração bastante complexo e confuso. Obtivemos resultados incoerentes na configuração dos equipamentos a monitorizar. Isto é, na configuração de equipamentos idênticos, configurados da mesma forma, só alguns é que funcionavam, o que levou a abandonar a hipótese de esta ser implementada. Passamos assim para o estudo do MRTG.

66 48 CAPÍTULO 4. NETWORK GRAPHING SOLUTION - CACTI

67 Capítulo 5 Multi Router Traffic Grapher - MRTG 5.1 Enquadramento No âmbito descrito no enquadramento do capitulo anterior, segue então o estudo e implementação da ferramenta de monitorização MRTG. Procedemos da mesma forma do que com o Cacti, começamos por testar o MRTG numa maquina virtual, para analisar e testar o seu desempenho. 5.2 Introdução O MRTG consiste num script em Perl que usa o protocolo SNMP (Simple Protocol Network Management) para ler os registos de tráfego dos equipamentos a serem monitorizados. De um programa em C que registra os dados do tráfego e cria gráficos representando o tráfego da rede monitorizada. Estes gráficos são incluídos em páginas web que podem ser visualizadas de qualquer browser. O MRTG é um dos softwares mais utilizados para monitorização, além de gerar gráficos em tempo real, cria também gráficos semanais, mensais e anuais, que permitem visualizar a evolução do tráfego na rede. Isto é possível porque o MRTG guarda um log de todos os dados que ele conseguiu ler do equipamento. Esse log é automaticamente consolidado, e com isso, pode ar- 49

68 50 CAPÍTULO 5. MULTI ROUTER TRAFFIC GRAPHER - MRTG mazenar todos os dados relevantes de todo o tráfego dos últimos 2 anos. Isto tudo é realizado de uma maneira muito eficiente, e com pouca carga computacional. 5.3 História da criação do MRTG Em 1994, Tobias Oetiker, trabalhava para um site onde tinha um link de 64kbit para o mundo externo. Obviamente todos estavam interessados em saber como estava a utilização do link. Então escreveu um rápido programa que constantemente actualizava um gráfico na web, mostrando a utilização do link de Internet. Isso finalmente tornou-se um script configurável em Perl chamado MRTG-1.0 que foi lançado na primavera de Em Janeiro de 1996, recebeu um de Dave Rand perguntando se tinha ideia do porquê o MRTG ser tão lento. A programação do MRTG não era muito eficiente e era escrito inteiramente em Perl. Depois de uma semana, Dave sugeriu uma ideia para melhorar a velocidade do MRTG. Ele decidiu reescrever melhorar o código que demorava mais tempo na execução do MRTG. A ferramenta que ele desenvolveu melhorou a velocidade do MRTG em 40 vezes. Começou a distribuir cópias Beta para pessoas interessadas. Passou a receber muitas contribuições, muitos sugestões e correcções de bugs. O produto que se pode utilizar hoje não seria como é, se não fossem as contribuições e suporte que recebeu de muitas pessoas, [10]. 5.4 Características e funcionalidades Portabilidade MRTG corre na maioria das plataformas UNIX e Windows NT. Perl O MRTG é escrito em Perl e vem com todo o código fonte. SNMP MRTG usa uma implementação SNMP de alta portabilidade escrita toda em Perl. Não é necessário instalar qualquer pacote SNMP externo. Interface de Identificação As interfaces dos equipamentos podem ser identificadas pelo endereço IP, descrição, em adição ao número da interface normal.

69 5.5. INSTALAÇÃO E CONFIGURAÇÃO 51 Tamanho dos arquivos de Log fixos Os arquivos de log do MRTG não crescem. Graças ao uso de um algoritmo de consolidação de dados único. Configuração MRTG vem com um conjunto de ferramentas de configuração que tornam a configuração muito simples. Aparência A aparência das páginas produzidas pelo MRTG são facilmente configuráveis. 5.5 Instalação e configuração O MRTG requer os seguintes pacotes para funcionar: gcc, perl, gd, libpng, zlib. Caso a distribuição usada não os possuir, será necessário instala-los para o bom funcionamento do MRTG. Para instalar o MRTG executamos o seguinte comando: #yum install mrtg De seguida vamos criar uma directoria para cada instituição, onde será guardada toda a informação necessaria para a geração dos gráficos: #mkdir /var/www/html/monitor/core #mkdir /var/www/html/monitor/sc #mkdir /var/www/html/monitor/sas #mkdir /var/www/html/monitor/ese #mkdir /var/www/html/monitor/esa #mkdir /var/www/html/monitor/estg #mkdir /var/www/html/monitor/esenf #mkdir /var/www/html/monitor/esce Após a instalação dos pacotes e da criação das directorias, vamos agora criar os arquivos de configuração dos equipamentos que o MRTG irá monitorizar, através do comando cfgmaker. Vamos criar um para cada instituição a monitorizar. Indicando no comando a localização onde será armazenado o arquivo de configuração e a localização onde será gerada a pagina html com os gráficos, bem como o endereço IP do equipamento a ser monitorizado. Rede de Core do IPVC:

70 52 CAPÍTULO 5. MULTI ROUTER TRAFFIC GRAPHER - MRTG #cfgmaker --global workdir: /var/www/html/monitor/core --output /etc/mrtg/core.cfg --global options[_]: growright,bits public@ Serviços Centrais: #cfgmaker --global workdir: /var/www/html/monitor/sc --output /etc/mrtg/sc.cfg --global options[_]: growright,bits public@ Serviços de acção Social: #cfgmaker --global workdir: /var/www/html/monitor/sas --output /etc/mrtg/sas.cfg --global options[_]: growright,bits public@ Escola Superior de Educação: #cfgmaker --global workdir: /var/www/html/monitor/ese --output /etc/mrtg/ese.cfg --global options[_]: growright,bits public@ Escola Superior Agrária: #cfgmaker --global workdir: /var/www/html/monitor/esa --output /etc/mrtg/esa.cfg --global options[_]: growright,bits public@ Escola Superior de Tecnologia e Gestão: #cfgmaker --global workdir: /var/www/html/monitor/estg --output /etc/mrtg/estg.cfg --global options[_]: growright,bits public@

71 5.5. INSTALAÇÃO E CONFIGURAÇÃO 53 Escola Superior de Enfermagem: #cfgmaker --global workdir: /var/www/html/monitor/esenf --output /etc/mrtg/esenf.cfg --global options[_]: growright,bits public@ Escola Superior de ciências Empresariais: #cfgmaker --global workdir: /var/www/html/monitor/esce --output /etc/mrtg/esce.cfg --global options[_]: growright,bits public@ De seguida, criamos os ficheiros de index (index.html) para cada uma das instalações a monitorizar. Através dos seguintes comandos: # indexmaker --output=/var/www/html/monitor/core/index.html /etc/mrtg/core.cfg # indexmaker --output=/var/www/html/monitor/sc/index.html /etc/mrtg/sc.cfg # indexmaker --output=/var/www/html/monitor/sas/index.html /etc/mrtg/sas.cfg # indexmaker --output=/var/www/html/monitor/ese/index.html /etc/mrtg/ese.cfg # indexmaker --output=/var/www/html/monitor/esa/index.html /etc/mrtg/esa.cfg # indexmaker --output=/var/www/html/monitor/estg/index.html /etc/mrtg/estg.cfg

72 54 CAPÍTULO 5. MULTI ROUTER TRAFFIC GRAPHER - MRTG # indexmaker --output=/var/www/html/monitor/esenf/index.html /etc/mrtg/esenf.cfg # indexmaker --output=/var/www/html/monitor/esce/index.html /etc/mrtg/esce.cfg Vamos agora editar o ficheiro mrtg.conf situado em /etc/htt pd/con f.d/ : #gedit /etc/httpd/conf.d/mrtg.conf & E alteramos-lo para seguinte: Alias /mrtg /var/www/html/monitor/mrtg <Location /mrtg> Order deny,allow Deny from all Allow from /24 </Location> Vamos agora executar o mrtg, para cada um dos ficheiros de configuração gerados: # mrtg /etc/mrtg/core.cfg # mrtg /etc/mrtg/sc.cfg # mrtg /etc/mrtg/sas.cfg # mrtg /etc/mrtg/ese.cfg # mrtg /etc/mrtg/esa.cfg # mrtg /etc/mrtg/estg.cfg # mrtg /etc/mrtg/esenf.cfg # mrtg /etc/mrtg/esce.cfg

73 5.5. INSTALAÇÃO E CONFIGURAÇÃO 55 Figura 5.1: Erro Ao executar estes comandos é provável que surge um erro como mostra a figura 5.1. Para resolve-lo usamos o seguinte comando: #env LANG=C /usr/bin/mrtg /etc/mrtg/core.cfg Se for necessário, caso torne a surgir um erro, executar o comando mais do que uma vez. Vamos agora editar o ficheiro crontab, que se encontra em /etc/crontab, com o objectivo de executar o MRTG de cinco em cinco minutos. O crontab permite agendar e executar tarefas numa certa periodicidade. Para tal, adicionamos as seguintes linhas ao ficheiro: */5 * * * * root /usr/bin/mrtg /etc/mrtg/core.cfg --logging /var/log/core.log */5 * * * * root /usr/bin/mrtg /etc/mrtg/sc.cfg --logging /var/log/sc.log */5 * * * * root /usr/bin/mrtg /etc/mrtg/sas.cfg --logging /var/log/sas.log */5 * * * * root /usr/bin/mrtg /etc/mrtg/ese.cfg --logging /var/log/ese.log */5 * * * * root /usr/bin/mrtg /etc/mrtg/esa.cfg --logging /var/log/esa.log */5 * * * * root /usr/bin/mrtg /etc/mrtg/estg.cfg --logging /var/log/estg.log */5 * * * * root /usr/bin/mrtg /etc/mrtg/esenf.cfg --logging /var/log/esenf.log */5 * * * * root /usr/bin/mrtg /etc/mrtg/esce.cfg --logging /var/log/esce.log

74 56 CAPÍTULO 5. MULTI ROUTER TRAFFIC GRAPHER - MRTG Adicionamos uma linha por cada ficheiro de configuração gerado, ou seja para cada uma das instituições a monitorizar. Neste momento, já podemos observar o resultado destas configurações em onde é nos apresentado uma pagina html principal com links para as diferentes instituições, como nos apresenta a figura 5.2. Figura 5.2: Página principal 5.6 Autenticação Com o objectivo de controlar e restringir o acesso a informação gerada pelo MRTG, vamos configurar o acesso a essa informação com autenticação.

75 5.6. AUTENTICAÇÃO 57 Para tal, vamos começar por criar uma directoria onde ficarão guardadas as passwords associadas aos utilizadores. #mkdir /var/www/passwords Optamos por criar um utilizador que poderá aceder a toda a informação gerada pelo MRT G, ou seja, a todas as instituições. E criamos um utilizador para cada uma das instituições a monitorizar. Assim um dado utilizador poderá apenas consultar a informação referente a instituição a ele associada. Vamos então criar o utilizador (Administrador) e associar-lhe uma password, criando o ficheiro passwords, usando o seguinte comando: #/usr/bin/htpasswd -c /var/www/passwords/passwords manager No qual manager é o utilizador, logo de seguida é nos pedido a password a associar a este utilizador, password esta que definimos como manageripvc2007. Este utilizador poderá aceder a informação de todas as instituições. De seguida, criamos um utilizador para cada instituição desta forma: #/usr/bin/htpasswd /var/www/passwords/passwords sc #/usr/bin/htpasswd /var/www/passwords/passwords sas #/usr/bin/htpasswd /var/www/passwords/passwords ese #/usr/bin/htpasswd /var/www/passwords/passwords esa #/usr/bin/htpasswd /var/www/passwords/passwords estg #/usr/bin/htpasswd /var/www/passwords/passwords esenf #/usr/bin/htpasswd /var/www/passwords/passwords esce Em que, para cada um deles nos será pedido para definir uma password. Optamos por uma password idêntica as iniciais de cada instituição.

76 58 CAPÍTULO 5. MULTI ROUTER TRAFFIC GRAPHER - MRTG Vamos agora editar o ficheiro htt pd.con f situado em /etc/htt pd/con f /htt pd.con f. Com o objectivo de configurar para cada directoria, o tipo de autenticação no acesso, bem como os utilizadores autorizados a aceder a mesma. Para tal, adicionamos as seguintes linhas ao ficheiro htt pd.con f : <Directory "/var/www/html/monitor/core"> AuthType Basic AuthName "Core" AuthUserFile /var/www/passwords/passwords Require user manager </Directory> <Directory "/var/www/html/monitor/sc"> AuthType Basic AuthName "Servicos Centrais" AuthUserFile /var/www/passwords/passwords Require user sc manager </Directory> <Directory "/var/www/html/monitor/sas> AuthType Basic AuthName "Servicos Accao Social" AuthUserFile /var/www/passwords/passwords Require user sas manager </Directory> <Directory "/var/www/html/monitor/ese> AuthType Basic AuthName "Escola Superior de Educacao"

77 5.6. AUTENTICAÇÃO 59 AuthUserFile /var/www/passwords/passwords Require user ese manager </Directory> <Directory "/var/www/html/monitor/esa> AuthType Basic AuthName "Escola Superior Agraria" AuthUserFile /var/www/passwords/passwords Require user esa manager </Directory> <Directory "/var/www/html/monitor/estg> AuthType Basic AuthName "Escola Superior de Tecnologia e Gestao" AuthUserFile /var/www/passwords/passwords Require user estg manager </Directory> <Directory "/var/www/html/monitor/esenf> AuthType Basic AuthName "Escola Superior de Enfermagem" AuthUserFile /var/www/passwords/passwords Require user esenf manager </Directory> <Directory "/var/www/html/monitor/esce> AuthType Basic AuthName "Escola Superior de Ciencias Empresariais" AuthUserFile /var/www/passwords/passwords

78 60 CAPÍTULO 5. MULTI ROUTER TRAFFIC GRAPHER - MRTG </Directory> Require user esce manager Podemos observar o resultado destas configurações nas figuras 5.3. Figura 5.3: Pedido de Autenticação Caso a autenticação seja mal sucedida será apresentado uma mensagem de erro como mostra a figura 5.4.

79 5.7. GRÁFICOS GERADOS 61 Figura 5.4: Erro de Autenticação

80 62 CAPÍTULO 5. MULTI ROUTER TRAFFIC GRAPHER - MRTG Figura 5.5: Monitorização dos Serviços Centrais do IPVC

81 5.7. GRÁFICOS GERADOS Gráficos gerados Podemos observar através das figuras 5.5 e 5.6, dois exemplos de paginas geradas pelo MRTG, neste caso, o comportamento do tráfego nos Serviços Centrais do IPVC e do Switch de Core do IPVC. Nestas figuras, é-nos apresentado um gráfico para cada interface do equipamento monitorizado. Para melhor compreensão dos gráficos, optamos por alterar as legendas geradas automaticamente pelo MRTG. Para tal, tivemos que editar o ficheiro index.html para cada instituição, localizados em /var/www/html/monitor/. Figura 5.6: Monitorização do Switch de Core do IPVC

82 64 CAPÍTULO 5. MULTI ROUTER TRAFFIC GRAPHER - MRTG Podemos ter uma visualização da monitorização por períodos, isto é, para cada interface podemos visualizar os gráficos gerados por dia, semana, mês e ano. Como nos mostram as figuras 5.7 e 5.8. Apresentando ainda dados estatísticos, como médias, valores máximos atingidos e valores instantâneos. Figura 5.7: Gráficos detalhados da interface

83 5.7. GRÁFICOS GERADOS 65 Figura 5.8: Gráficos detalhados da interface

84 66 CAPÍTULO 5. MULTI ROUTER TRAFFIC GRAPHER - MRTG 5.8 Considerações finais Após o estudo e implementação desta ferramenta, esta demonstrou um excelente desempenho e uma fácil configuração. Através desta, foram aperfeiçoados conceitos de routing e de configuração dos equipamentos a monitorizar. É muito gratificante ter contribuído para a implementação desta ferramenta, visto que vai ser de uma grande utilidade na gestão e administração da rede do IPVC. Alcançou por completo todos os objectivos pretendidos. Neste momento pode ser consultada a informação gerada por esta ferramenta em que se encontra em funcionamento no Data Center do IPVC. Esta permite a monitorização de todas as instalações da instituição.

85 Capítulo 6 Servidor de correio electrónico Postfix com Ldap 6.1 Enquadramento A filosofia da solução Postfix com Ldap passa pela centralização dos dados relativos a cada conta de correio numa base de dados. O nosso servidor de correio vai utilizar esta base de dados para saber onde deve guardar as mensagens para cada caixa de correio e onde deve procurá-las para as disponibilizar aos utilizadores. Uma vez que esta base de dados vai ser consultada muitas vezes, é de importância fundamental que o seu funcionamento seja o mais rápido possível. Esta é uma das razões pelas quais se utiliza a base de dados LDAP. 6.2 Introdução LDAP O que é o LDAP? O LDAP (Lightweight Directory Access Protocol) é uma tecnologia em rápido crescimento de acesso a informação contida em directórios. Uma vez que é um standard aberto, independente da 67

86 68 CAPÍTULO 6. SERVIDOR DE CORREIO ELECTRÓNICO POSTFIX COM LDAP implementação, o LDAP fornece uma arquitectura extensível para o armazenamento centralizado e gestão de informação que necessite de estar disponível para os sistemas e serviços distribuídos dos dias de hoje. Tal como o DNS (Domain Name System) é usado como sistema de procura de endereços IP em praticamente todas as redes (locais ou Internet), também o LDAP se impôs rapidamente como o método de acesso a informação contida em directórios. É suportado por praticamente todos os sistemas operativos de rede. Convém, no entanto, esclarecer alguns conceitos básicos, para melhor se perceber o que é, e para que serve o LDAP. Um directório no contexto do LDAP, ao contrário do que o nome pode sugerir, não são as pastas de um disco rígido ou de uma disquete. A designação directório provém apenas da similaridade da estrutura utilizada para guardar a informação com as árvores de directórios dos discos rígidos. Um directório é então uma base de dados especializada ou optimizada para leitura e pesquisa. É concebida para ser acedida muito mais frequentemente do que actualizada. A informação guardada em directórios tem tendência a ser mais estática, do que aquela que habitualmente é guardada numa base de dados relacional. Por exemplo, para guardar informação acerca de impressoras (a sua localização, o modo de se aceder, em que piso está) deve-se utilizar um directório, pois é informação pouco susceptível de se alterar frequentemente, enquanto que para se guardar informação acerca dos trabalhos em espera para serem imprimidos numa determinada impressora, já se deve utilizar um modelo de bases de dados mais clássico, pois é informação que está constantemente a ser actualizada. Nas bases de dados genéricas, utiliza-se normalmente um método de acesso muito poderoso, o SQL, que permite fazer perguntas complexas à base de dados, mas com o custo do tamanho e complexidade do programa. O LDAP é um protocolo de acesso simplificado e optimizado, que pode ser usado em aplicações leves e relativamente simples de implementar. O LDAP é portanto um protocolo para aceder a serviços de directório, como inserir, consultar e modificar informação. O modelo de funcionamento é o de cliente-servidor. É um standard e por isso implementações diferentes são compatíveis (um cliente da Novel pode aceder a um servidor OpenLDAP), [11].

87 6.2. INTRODUÇÃO 69 Um pouco de historia Nos anos 70, a integração das comunicações com as tecnologias da computação levaram ao desenvolvimento de novas tecnologias de comunicação. Muitos dos sistemas proprietários que eram desenvolvidos eram incompatíveis com outros sistemas. Tornou-se necessário o surgimento de standards para permitirem que equipamento e sistemas de diferentes fornecedores interagissem entre si. Isto resultou em duas abordagens distintas na forma de produzir standards. Uma abordagem foi a proposta da ISO, que se baseava no modelo OSI (baseado em camadas) e definia standards usando um processo formal de comités, sem requerer implementações. Outra abordagem menos formal e mais dinâmica, foi crescendo na Internet. Qualquer pessoa podia propor ou comentar um standard sobre a forma de um RFC (Request For Comments). Depois de ser aprovado, implementado e usado por um período de tempo, tornava-se eventualmente num standard (STD). Os protocolos da OSI desenvolveram-se lentamente, e uma vez que correr toda a pilha de protocolos OSI consumia muitos recursos, este modelo acabou por não singrar efectivamente, especialmente no mercado dos computadores mais pequenos. Entretanto, o TCP/IP e a Internet estavam a desenvolver-se rapidamente e a ser postos em prática. Contudo, os protocolos da OSI trataram assuntos importantes em sistemas largamente distribuídos, entre os quais os serviços de directórios. O CCITT, parceira da ISO, criou o standard X.500 em O X.500 organiza entradas de directórios num espaço de nomes hierárquico capaz de suportar grandes capacidades de informação. Define também capacidades poderosas de procura de informação num directório. O X.500 especificava que a comunicação entre um cliente de um directório e o servidos do directório usava o Directory Acess Protocol (DAP). No entanto, sendo o DAP um protocolo da camada de aplicação, usálo implicava suportar toda a pilha de protocolos do modelo OSI. A Internet (que entretanto adoptara definitivamente o TCP/IP) não estava para aí virada, pois não queria perder o mercado dos computadores menos poderosos, com recursos insuficientes para suportar o modelo OSI. Nas empresas respostas a perguntas como Qual o endereço do líder do projecto? e Onde está a próxima impressora a cores podiam levar muito tempo a ser respondidas. Os utilizadores

88 70 CAPÍTULO 6. SERVIDOR DE CORREIO ELECTRÓNICO POSTFIX COM LDAP queriam também contas centralizadas independentemente das workstations que usassem. Um serviço de directórios era a solução para estes problemas, mas as empresas (especialmente as não muito grandes) não estavam dispostas a suportar os custos de utilizar a pilha de protocolos da OSI, quando o mais leve TCP/IP era tão adequado às suas necessidades. Era então desejável o aparecimento de um protocolo mais leve, ou menos consumidor de recursos, que servisse de interface para um servidor de directório X.500. Surgiu então o LDAP, como alternativa mais leve ao DAP. O LDAP precisava apenas da pilha de protocolos TCP/IP, muito mais leve e popular que o modelo da OSI. O LDAP simplificava também algumas operações do X.500 e omitia algumas das suas funcionalidades mais obscuras. O LDAP teve ainda dois percursores, o DAS e o DIXIE. Eram no entanto RFCs informativos, que não pretendiam ser standards. A primeira versão do LDAP foi definida no X.500 Lightweight Directory Access Protocol (RFC 1487), sendo substituído pelo Lightweight Directory Access Protocol (RFC 1777). O LDAP aprofundava as ideias do DAS e do DIXIE. Era mais neutro relativamente às implementações e reduzia a complexidade dos clientes para incentivar o surgimento de aplicações que suportassem directórios. Muito do trabalho do DIXIE e do LDAP foi feito na Universidade de Michigan, que fornece implementações referência do LDAP e mantém páginas Web relacionadas com o LDAP. Actualmente o LDAP já vai na versão 3, [11]. Vantagens na sua utilização Um directório específico a uma determinada aplicação, é um directório que guarda apenas a informação necessária para uma aplicação particular e não é acessível por outras aplicações. Uma vez que um serviço directório com todas as funcionalidades que lhe são exigidas é de construção complexa, esse tipo de directórios são tipicamente muito limitados (provavelmente guardam apenas um tipo de informação, não têm capacidades genéricas de procura, não suportam replicação e faltam-lhes as ferramentas de administração). Num ambiente desse género, cada aplicação cria e gere o seu próprio directório, o que rapidamente torna um pesadelo a sua administração. O LDAP vem colmatar esta brecha, permitindo a quem desenvolve aplicações abstrair-se dos

89 6.2. INTRODUÇÃO 71 problemas de gestão e administração dos directórios e preocupar-se com o desenvolvimento propriamente dito das aplicações. Da mesma maneira que os programadores confiam a infraestrutura das suas comunicações ao TCP/IP libertando-se assim de questões de comunicação de baixo nível, também podem contar com serviços de directórios poderosos e completos, integrando o protocolo LDAP nas suas aplicações. Quando as aplicações acedem a um protocolo standard comum, concebido duma forma correcta, em vez de utilizarem directórios específicos para cada aplicação, a redundância pode ser eliminada, e os riscos de segurança mais controláveis. Por exemplo, num único directório pode ser guardada informação sobre o telefone, e user name e password de uma entidade. As diversas aplicações podem aceder aos campos que lhe interessam em vez de terem que gerir um directório próprio sobre essa entidade. A aplicação de iria buscar os s ao mesmo directório em que a aplicação de login a informação acerca das contas de utilizador para autenticar uma abertura de sessão de trabalho. Mas talvez a principal vantagem de se utilizar LDAP seja o facto de ser independente da plataforma. Por ser apenas um protocolo, que define o que deverão ser as implementações, e não uma implementação em particular, praticamente todos os sistemas operativos suportam LDAP e existem implementações para os mesmos. Uma vez que é um standard da Internet, as aplicações não têm de se preocupar com o tipo de servidor LDAP a que estão a aceder. Ele será compatível. Talvez por isso, cada vez mais aplicações suportam o LDAP. Por contraste com os SGBD clássico, uma aplicação que se queira ligar a uma base de dados, tem que ser feita especificamente para o SGBD em causa (Microsoft SQL Server, MySQL, Postgres, Oracle). Até numa simples página PHP, as funções de acesso a uma base de dados (relacional) são diferentes de SGBD para SGBD. Com o LDAP, a aplicação basta saber como aceder ao servidor. Não lhe interessa se a implementação do servidor é OpenLDAP ou e- Directory. O LDAP é particularmente útil para guardar informação que se queira aceder a partir de muitas localizações. Por exemplo, uma multinacional pode ter a informação relativa aos seus empregados centralizada, num determinado servidor LDAP, sendo esta facilmente acedida a partir de qualquer instalação da empresa, desde que tenha acesso à Internet. Não é necessário a informação estar duplicada em cada computador da empresa, ou em cada edifício da mesma.

90 72 CAPÍTULO 6. SERVIDOR DE CORREIO ELECTRÓNICO POSTFIX COM LDAP Outra grande vantagem é a rapidez de acesso aos dados, uma vez que as estruturas que suportam os mesmos são optimizadas para isso mesmo. Os servidores LDAP podem manter a informação replicada, permitindo puxar a informação para instalações remotas, aumentando a segurança. Esta característica é facilmente configurável e está embutida no LDAP. Por contraste, a maioria dos fornecedores de SGBDs cobram mais por esta característica, que ainda por cima é muito mais difícil de gerir. O LDAP permite delegar permissões de acesso e/ou escrita dos dados dependendo de quem faz o pedido, que dados estão a ser pedidos, onde estão os dados guardados, e outros aspectos do registo a ser modificado. Isto é feito directamente pelo directório LDAP, não sendo necessário fazer medidas de segurança ao nível das aplicações. Por exemplo, um determinado grupo de utilizadores pode ter permissão apenas para modificar a morada ou o local de trabalho de um empregado, mas não poder alterar o seu salário. Resumindo, o LDAP tem 5 vantagens principais: É um standard aberto (independente da implementação); Está disponível em virtualmente todos os sistemas operativos (independente da plataforma); É relativamente fácil produzir aplicações que lidam com LDAP (implementação fácil), permitindo aos programadores abstraírem-se das questões de baixo nível dos directórios; Rapidez no acesso à informação; Replicação da Informação. Desvantagens na sua utilização No entanto, à medida que o LDAP vai evoluindo, vai a pouco e pouco tornando-se num protocolo pesado. Se antes era extremamente fácil instalar e configurar o LDAP, actualmente já é tarefa que exige arregaçar as mangas, pois cada vez tem mais prérequisitos (software do qual precisa). Para dar um exemplo, as últimas versões do OpenLDAP, a implementação de LDAP open source mais utilizada, exige 6 pacotes distintos de software que devem estar instalados se queremos tirar

91 6.2. INTRODUÇÃO 73 a máxima funcionalidade do nosso servidor LDAP (OpenSSL para o Transport Layer Security, Kerberos, SASL (Cyrus), Berkeley DB como suporte para a base de dados, suporte para threads e TCP Wrappers). Alguns deles já vêm instalados no sistema operativo, mas o LDAP tem vindo a perder a sua leveza. Não existe nenhuma entidade oficial para registar os schemas. Os schemas são os ficheiros que definem os objectos a armazenar (incluindo os seus atributos) - no glossário das bases de dados relacionais seriam a estrutura das tabelas. Uma vez que o LDAP se quer universal, esta continua a ser uma lacuna, pois qualquer um pode alterar os ficheiros schema e inviabilizar o acesso de quem não está consciente das alterações. Para além disso, falta um sistema de replicação estandardizado. As replicações já existem na maioria das implementações, mas não fazem parte do standard. Como é normal nestas situações, diferentes implementações são incompatíveis. Apesar de todos os mecanismos de segurança que já suporta, o maior problema apontado ao LDAP são as capacidades de autenticação limitadas. Isto apesar do suporte para SASL ou do uso de SSL como uma camada independente de encriptação. Contudo faltam ainda mecanismos mais sofisticados de controlar os acessos. Os clientes têm vindo a mostrar a tendência de se tornarem cada vez mais complexos e a perder um pouco a simplicidade que os caracteriza. Funcionamento LDAP Para se compreender o funcionamento do LDAP, é necessário primeiro esclarecer alguns conceitos dos directórios em geral e do X.500 em particular. A parte mais importante de cada directório é o seu espaço de nomes. Um espaço de nomes é um método de referenciar cada entrada num directório. Por exemplo, uma lista telefónica, falando a grosso modo, utiliza um espaço de nomes hierárquico plano, consistindo apenas da cidade e do nome da pessoa. Cada espaço de nomes define que atributos são precisos para identificar univocamente uma entrada. Esta referência pode ser então usada para devolver ou modificar uma entrada do seu espaço de nomes. Tal conjunto consistiria no nome da pessoa, a morada e o número de telefone.

92 74 CAPÍTULO 6. SERVIDOR DE CORREIO ELECTRÓNICO POSTFIX COM LDAP No caso do LDAP, e uma vez que reflecte as suas origens no X.500, é utilizado também um espaço de nomes hierárquico. As entradas são organizadas numa estrutura em árvore chamada Directory Information Tree (DIT). As entradas situam-se na DIT consoante o seu nome distinto (Distinguished Name - DN). O DN é um nome único que identifica sem ambiguidades cada entrada. Os DNs são constituídos por uma sequência de Relative Distinguished Names (RDN). Cada RDN corresponde a um ramo da árvore e um DN é a concatenação dos vários RDNs de uma entrada desde a folha até à raiz. Na analogia da lista telefónica, os RDNs seriam a cidade e o nome da pessoa e o DN é o conjunto da cidade e do nome da pessoa, pois com eles conseguimos identificar univocamente uma instância da lista telefónica. O número de telefone e a morada seriam os restantes atributos. Pode-se organizar, por exemplo, entradas de empresas, e depois pode-se dividir a árvore nos vários departamentos das mesmas, e assim por diante. Ou então termos como raiz uma universidade, com ramos que representam as unidades fulcrais, por sua vez divididos em escolas, que ainda poderiam conter informação dos alunos que os frequentam como mostra a figura 6.1: Figura 6.1: Exemplo de uma árvore (DIT) de um directório LDAP Cada objecto (também referido como entrada) num directório pode pertencer a uma ou mais

93 6.2. INTRODUÇÃO 75 classes de objectos. Uma classe de objectos descreve o conteúdo e a finalidade do objecto. Contém uma lista de atributos obrigatórios que cada objecto dessa classe tem de ter e uma lista de atributos opcionais. A classe de um determinado objecto é também um atributo do mesmo. Tal como no paradigma da programação orientada a objectos, também o LDAP suporta herança simples e múltipla e classes abstractas. No exemplo o objecto mais abaixo filipe ou pedrobarbosa são alunos da escola estg que pertence ao grupo users do ipvc, que neste caso faz o papel de raíz. Os seus DN s seriam dc = ipvc, users, estg, sn=filipe e sn=pedro respectivamente. Este mesmo directório poderia conter outro tipo de informação, como por exemplo os computadores da universidade. Essa é precisamente outra vantagem da estrutura organizacional de um directório. Não estamos vinculados a aceitar apenas um determinado tipo de objectos num nível da árvore. Resumindo, uma entrada num directório descreve um objecto (pessoa, dispositivo, localização, organização). Uma classe de objectos é uma descrição geral (um modelo ou molde) de um objecto. Um esquema (schema) define que classes de objectos são permitidos num directório (e onde), que atributos têm que conter, quais os atributos opcionais e a sintaxe de cada atributo. OpenLDAP O LDAP pode ser usado em qualquer tipo de rede TCP/IP e é um padrão aberto, permitindo que existam produtos para várias plataformas. Uma das suites mais usadas é o OpenLDAP (GPL). Uma vez instalado, o OpenLDAP pode ser configurado através do arquivo sldap.conf, encontrado no directório /etc. O servidor é o daemon sladap e o cliente o ldapsearch, que é originalmente um utilitário de modo texto mas que pode trabalhar em conjunto com vários front-ends gráficos. O OpenLDAP pode ser usado em conjunto com vários clientes comerciais e permite estabelecer vários níveis de permissões e controle de acesso para os dados compartilhados, além de suportar encriptação. Note que embora seja possível ter acesso à base de dados remotamente, o LDAP não é um protocolo frequentemente usado na Internet, apenas em Intranets, sobretudo de grandes empresas,

94 76 CAPÍTULO 6. SERVIDOR DE CORREIO ELECTRÓNICO POSTFIX COM LDAP já que quanto maior é o número de usuários e de documentos disponíveis, maior é sua utilidade NSSWITCH NSSWITCH (Name Service Switch) permite a substituição de vários ficheiros de configuração (ex: /etc/passwd, /etc/group,/etc/host) através de uma ou várias bases de dados centralizadas. A sua função é informar o sistema da ordem pela qual deverá consultar vários serviços para resolver informação sobre utilizadores com a vantagem do mecanismo usado para aceder a essas bases de dados, ser ele também configurável. No caso usado para este trabalho, servirá para procurar os utilizadores que se vão autenticar para aceder às suas mensagens de correio electrónico POSTFIX É um software livre de MTA (Mail Transfer Agent), um programa para plataformas Unix-like que permite a transferência e entrega de mail. È reconhecido como um programa rápido e fácil de administrar, sendo uma forma alternativa e segura ao vulgarmente usado Sendmail MTA. Um dos pontos forte do Postfix é a sua resistência contra os buffer overflows, uma outra é a sua capacidade de tratamento de quantidade enorme de mails. È constituído por vários daemons (smtpd, pickup, cleanup, maildrop, sendmail, incoming, etc.) que cooperam entre si em rede. Cada daemon preenche uma simples tarefa usando o mínimo de privilégios. Deste modo se um dos daemons for comprometido, o impacto permanecerá limitado somente a esse daemon, evitando o alastramento ao todo o sistema. Só existe um único processo com privilégios de root e alguns que actualmente escrevem no disco ou invocam programas externos. Usa o protocolo SMTP na porta tcp 25, para entrega local e reenvio de mails. Uma das vantagens em relação ao Sendmail é que o Sendmail só armazena as mensagens no formato mailbox enquanto que o Postfix guarda as mensagens em mailbox e no formato maildir, [15].

95 6.3. IMPLEMENTAÇÃO COURIER-POP/IMAP Programa incluído nas distribuições Linux, para entrega de mensagens através dos protocolos POP e IMAP, POPS e IMAPS. O protocolo POP (Post Office Protocol) serve para descarregar as mensagens de mail existente num servidor e aceita pedidos na porta 110. Os clientes ligam-se a um servidor que armazena as mensagens em spool, e depois de se autenticarem, descarregam as mensagens através de um programa cliente de mail. Depois de descarregar as mensagens, esta ficam armazenadas localmente no posto onde se efectuou a ligação ao servidor. O protocolo IMAP (Internet Message Access Protocol) serve para ler o correio Electrónico de um servidor, mas ao contrário do POP, as mensagens permanecem no servidor. Este protocolo permite aceder às mensagens armazenadas num servidor, através de qualquer ponto ligado à Internet, existindo várias frameworks, para proporcionar a leitura através de um browser, recorrendo à criação de pastas, podemos visualizar sempre a mesma estrutura. Aceita pedidos na porta 143 e as mensagens não são totalmente lidas, somente os headers são enviado para o programa cliente e caso exista um grande número de mensagens, este processo pode sobrecarregar a largura de banda utilizada na ligação. Estes dois protocolos têm um ponto fraco em comum, ambos transmitem em clear text, o que pode permitir a leitura das mensagens por pessoas que estejam à escuta na rede. Por este facto ambos os protocolos possuem uma variante segura servindo-se do protocolo de encriptação de dados SSL. Protocolo baseado na tecnologia de Public Keys, permite a transmissão de dados entre dois postos, de forma que só o destinatário, possuindo a chave para desencriptar os dados, os torne compreensíveis. O protocolo POPS aceita ligações na porta 995 de forma segura, enquanto que o IMAPS aceita ligações na porta 993. Para implementação destes protocolos tivemos que recorrer à criação de um certificado, para o servidor enviar nas ligações seguras. 6.3 Implementação Este trabalho foi elaborado no sistema operativo OpenSuse 10.2 e foram utilizadas/instaladas as seguintes ferramentas: Openldap2, Openldap-client, Postfix, Courier Imap e Courier-Authib.

96 78 CAPÍTULO 6. SERVIDOR DE CORREIO ELECTRÓNICO POSTFIX COM LDAP Os pacotes Openldap, Openldap-client e Postfix são pacotes base do OpenSuse. Podem ser instalados a partir do dvd do sistema operativo Configuração do OpenLDAP Configurar o serviço SLDAP Configurar o ficheiro /etc/openldap/slapd.con f. Foram alterados as seguintes directivas: # Directives needed to implement policy: ############# #access to dn.base="" # by * read #access to dn.base="cn=subschema" # by * read #access to attrs=userpassword,userpkcs12 # by self write # by * auth #access to attrs=shadowlastchange # by self write # by * read access to * by * read ############################# # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! ####################################################################### # BDB database definitions

97 6.3. IMPLEMENTAÇÃO 79 ####################################################################### allow bind_anon_cred loglevel 0 database bdb suffix "dc=ipvc,dc=pt" checkpoint cachesize rootdn "cn=admin,dc=ipvc,dc=pt" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw {CRYPT}EkRwsbhTioLjg Configuração de arranque: pedrolinux:/#chkconfig -add ldap Arranque do serviço: pedrolinux:/#service ldap start Paragem do serviço para continuar com a configuração: pedrolinux:/#service ldap stop Criar um ficheiro /root/ldap.ldi f com a estrutura que queremos criar na Base de Dados do LDAP: dn: dc=ipvc, dc=pt dc: ipvc o: ipvc objectclass: dcobject objectclass: organization dn: ou=users, dc=ipvc, dc=pt ou: users

98 80 CAPÍTULO 6. SERVIDOR DE CORREIO ELECTRÓNICO POSTFIX COM LDAP objectclass: top objectclass: organizationalunit dn: ou=computers, dc=ipvc, dc=pt ou: computers objectclass: top objectclass: organizationalunit dn: ou=groups, dc=ipvc, dc=pt ou: groups objectclass: top objectclass: organizationalunit dn: ou=imapd, dc=ipvc, dc=pt ou: imapd objectclass: top objectclass: organizationalunit dn: ou=estg, ou=users, dc=ipvc, dc=pt ou: estg objectclass: top objectclass: organizationalunit dn: ou=ese, ou=users, dc=ipvc, dc=pt ou: ese objectclass: top objectclass: organizationalunit dn: ou=esce, ou=users, dc=ipvc, dc=pt

99 6.3. IMPLEMENTAÇÃO 81 ou: esce objectclass: top objectclass: organizationalunit dn: ou=esenf, ou=users, dc=ipvc, dc=pt ou: esenf objectclass: top objectclass: organizationalunit dn: ou=sas, ou=users, dc=ipvc, dc=pt ou: sas objectclass: top objectclass: organizationalunit dn: ou=sc, ou=users, dc=ipvc, dc=pt ou: sc objectclass: top objectclass: organizationalunit A estrutura utilizada pode ser visualizada através da figura 6.2. Adicionar os dados ao LDAP: pedrolinux:/#slapadd -f /etc/openldap/slapd.conf -l /root/ldap.ldif Arranque do serviço: pedrolinux:/#service ldap start Criar um ficheiro /root/user.ldi f com os utilizadores que queremos inserir na Base de Dados do LDAP: dn:uid=filipe,ou=estg,ou=users,dc=ipvc,dc=pt objectclass:person

100 82 CAPÍTULO 6. SERVIDOR DE CORREIO ELECTRÓNICO POSTFIX COM LDAP Figura 6.2: Estrutura LDAP utilizada

101 6.3. IMPLEMENTAÇÃO 83 objectclass:organizationalperson objectclass:top objectclass:inetorgperson objectclass:posixaccount homedirectory:/home/filipemiranda uid:filipe cn:engenheiro Filipe sn:miranda userpassword:{crypt}infy74gky1rjy uidnumber:1002 gidnumber:100 dn:uid=pedrobarbosa,ou=estg,ou=users,dc=ipvc,dc=pt objectclass:person objectclass:organizationalperson objectclass:top objectclass:inetorgperson objectclass:posixaccount homedirectory:/home/pedrobarbosa uid:pedrobarbosa cn:engenheiro Pedro sn:barbosa userpassword:{crypt}ekrwsbhtioljg uidnumber:1001 gidnumber:100

102 84 CAPÍTULO 6. SERVIDOR DE CORREIO ELECTRÓNICO POSTFIX COM LDAP Para gerar a password em CRYPT é necessário usar o site: gen web.html Adicionar os dados ao LDAP: pedrolinux:/#ldapadd -x -D cn=admin,dc=ipvc,dc=pt -W -f /root/user.ldif Comando para procurar um utilizador: pedrolinux:/#ldapsearch -x -D cn=admin,dc=ipvc,dc=pt -W uid=pedrobarbosa Por último criar os directórios raiz dos utilizadores e o directório de mail: pedrolinux:/ # mkdir /home/$user pedrolinux:/ # mkdir /home/$user/mail/new pedrolinux:/ # mkdir /home/$user/mail/cur pedrolinux:/ # mkdir /home/$user/mail/tmp pedrolinux:/ # chown $user:users $user pedrolinux:/ # chown $user:users $user/* pedrolinux:/ # chown $user:users $user/.* Terminados estes passos é necessário fazer alterações através da interface gráfica do cliente e servidor LDAP. Assim, acedemos ao centro de controlo Yast como mostra a figura 6.3. Seleccionamos o cliente LDAP e configuramo-lo como indica a figura 6.4.

103 6.3. IMPLEMENTAÇÃO 85 Figura 6.3: Centro de Controlo Yast - Cliente LDAP Clicando no botão Configuração Avançada temos acesso a outra caixa de diálogo onde, no separador Definições do Cliente, deveremos ter as seguintes configurações, figura 6.5: Por seu lado no separador Definições de Administração, deveremos observar as seguintes configurações figura 6.6. Depois de configurado o cliente LDAP, passamos ao servidor. Desta forma, seleccionamos o servidor LDAP no centro de controlo Yast, figura 6.7. Configuramo-lo da forma que mostra a figura abaixo e seleccionámos o botão Configurar, figura 6.8. Depois ser-nos-á mostrada outra caixa de diálogo onde teremos que ter em conta as seguintes configurações, figura 6.9. Depois de finalizados estes passos, temos o nosso serviço LDAP correctamente configurado.

104 86 CAPÍTULO 6. SERVIDOR DE CORREIO ELECTRÓNICO POSTFIX COM LDAP Figura 6.4: Configuração do Cliente LDAP

105 6.3. IMPLEMENTAÇÃO 87 Figura 6.5: Configuração avançada - Definições do cliente Figura 6.6: Configuração avançada - Definições de administração

106 88 CAPÍTULO 6. SERVIDOR DE CORREIO ELECTRÓNICO POSTFIX COM LDAP Figura 6.7: Centro de Controlo Yast - Servidor LDAP Figura 6.8: Configuração do Servidor LDAP

107 6.3. IMPLEMENTAÇÃO 89 Figura 6.9: Configuração do Servidor - Definições Globais Configuração do NSSWITCH Os ficheiros e configuração do Nsswitch encontra-se localizados em /etc. É necessário alterar o ficheiro /etc/nsswitch.con f da seguinte forma: passwd: compat shadow: files ldap group: compat #passwd: compat #group: compat hosts: files dns networks: files dns services: files ldap protocols: files rpc: files ethers: files netmasks: files

108 90 CAPÍTULO 6. SERVIDOR DE CORREIO ELECTRÓNICO POSTFIX COM LDAP netgroup: files ldap publickey: files bootparams: files automount: files nis aliases: files ldap passwd_compact: ldap group_compact: ldap shadow_compact: ldap passwd_compat: ldap group_compat: ldap Configurar o ficheiro /etc/ldap.con f que se encontra interligado com o serviço do nsswitch, foram alterados as seguintes directivas: rootbinddn cn=admin,dc=ipvc,dc=pt nss_schema rfc2307bis nss_base_passwd dc=ipvc,dc=pt?sub nss_base_shadow dc=ipvc,dc=pt?sub nss_base_group dc=ipvc,dc=pt?sub Configuração do POSTFIX Os ficheiros a configurar estão situados em /etc/pos f ix e são denominados por main.cf e master.cf. No main.cf houve necessidade de configurar algumas directivas nomeadamente a mynetworks para configurar o IP local do servidor, mydestination pelo facto do servidor estar ligado à Internet e responder a um domínio através de um registo dinâmico e home mailbox. As mensagens são entregues na directoria /home/user/mail. readme_directory = /usr/share/doc/packages/postfix/readme_files inet_protocols = all biff = no

109 6.3. IMPLEMENTAÇÃO 91 mail_spool_directory = /var/mail canonical_maps = hash:/etc/postfix/canonical virtual_alias_maps = hash:/etc/postfix/virtual virtual_alias_domains = hash:/etc/postfix/virtual relocated_maps = hash:/etc/postfix/relocated transport_maps = hash:/etc/postfix/transport sender_canonical_maps = hash:/etc/postfix/sender_canonical masquerade_exceptions = root masquerade_classes = envelope_sender, header_sender, header_recipient myhostname = pedrolinux.ipvc.pt program_directory = /usr/lib/postfix #inet_interfaces = ::1 inet_interfaces = all masquerade_domains = mydestination = $myhostname, localhost.$mydomain, pedrolinux.ipvc.pt defer_transports = #mynetworks_style = subnet mynetworks = / /8 disable_dns_lookups = no relayhost = mailbox_command = mailbox_transport = strict_8bitmime = no disable_mime_output_conversion = no smtpd_sender_restrictions = hash:/etc/postfix/access smtpd_client_restrictions = smtpd_helo_required = no smtpd_helo_restrictions = strict_rfc821_envelopes = no

110 92 CAPÍTULO 6. SERVIDOR DE CORREIO ELECTRÓNICO POSTFIX COM LDAP smtpd_recipient_restrictions = permit_mynetworks,reject_unauth_destination smtp_sasl_auth_enable = no smtpd_sasl_auth_enable = no smtpd_use_tls = no smtp_use_tls = no alias_maps = hash:/etc/aliases mailbox_size_limit = 0 message_size_limit = home_mailbox = Mail/ Configuração de arranque: pedrolinux:/#chkconfig -add postfix Arranque do serviço: pedrolinux:/#service postfix start Instalação e Configuração do COURIER IMAP Instalação dos pacotes Instalar pacotes courier-authlib e courier-imap: pedrolinux:/#rpm -ivh courier-authlib i586.rpm pedrolinux:/#rpm -ivh courier-imap i586.rpm Configuração do Courier Imap Activar os vários serviços inerentes ao Courier: pedrolinux:/#chkconfig -add courier-authdaemon pedrolinux:/#chkconfig -add courier-pop pedrolinux:/#chkconfig -add courier-pop-ssl

111 6.3. IMPLEMENTAÇÃO 93 pedrolinux:/#chkconfig -add courier-imap pedrolinux:/#chkconfig -add courier-imap-ssl Iniciar os vários serviços: pedrolinux:/#service courier-authdaemon start pedrolinux:/#service courier-pop start pedrolinux:/#service courier-pop-ssl start pedrolinux:/#service courier-imap start pedrolinux:/#service courier-imap-ssl start Os ficheiros e configuração do IMAP encontram-se localizados em /etc/courier. Foram alterados as seguintes directivas: MAILDIRPAT H = Mail Os ficheiros e configuração do IMAPS encontram-se localizados em /etc/courier. Foram alterados as seguintes directivas: MAILDIRPAT H = Mail Os ficheiros e configuração do POP encontram-se localizados em /etc/courier. Foram alterados as seguintes directivas: MAILDIRPAT H = Mail Os ficheiros e configuração do POPS encontram-se localizados em /etc/courier. Foram alterados as seguintes directivas: MAILDIRPAT H = Mail Para que o Certificado fosse criado, foi executado o seguinte comando: pedrolinux: # openssl req \

112 94 CAPÍTULO 6. SERVIDOR DE CORREIO ELECTRÓNICO POSTFIX COM LDAP > -x509 -nodes -days 365 \ > -newkey rsa:1024 -keyout ipvc.pem -out ipvc.pem 6.4 Testes realizados Utilizadores LDAP No sentido de verificar se os nossos utilizadores LDAP tinham sido correctamente criados e que o sistema operativo os reconhecia, fizemos um teste simples: alterar as permissões de uma pasta. Ao alterar o campo Owner, é-nos mostrada uma lista de utilizadores onde constam os utilizadores LDAP. Outra forma de testar os utilizadores LDAP resume-se a fazer login com o nome e palavrachave de um dos utilizadores. Esta situação também foi testada com sucesso SMTP e POP3 Testar o SMTP Para testar o SMTP procedemos aos seguintes passos: pedrolinux:/ # init S pedrolinux: # init 3 Fazemos login com o utilizador pedrobarbosa (poderia ser filipe). pedrobarbosa@pedrolinux: > telnet pedrolinux.ipvc.pt 25 HELO pedrolinux.ipvc.pt MAIL FROM: pedrobarbosa@pedrolinux.ipvc.pt

113 6.4. TESTES REALIZADOS 95 Figura 6.10: Testar utilizadores LDAP alterando o dono da pasta