Centro Universitrio UNIBENNETTCurso de Cincia da Computao

MonografiaTrabalho de Concluso de Curso

Rio de Janeiro 2007.2

2

FELIPE MARTINS RLLA ORIENTADOR: WILLIAM AUGUSTO R. DE SOUZA

DESENVOLVIMENTO, OTIMIZAO E IMPLEMENTAO DE SEGURANA EM SISTEMAS OPERACIONAIS LINUX PARA SERVIDORES DE E-MAIL CORPORATIVOS BASEADOS EM QMAIL

Monografia apresentada ao Centro Universitrio Bennett do Instituto Metodista Bennett, como parte dos requisitos para obteno do ttulo de Bacharel em Cincia da Computao.

Centro Universitrio Metodista Bennett

3

Rio de Janeiro 12/2007

4

TERMO DE APROVAO

FELIPE MARTINS ROLLA DESENVOLVIMENTO, OTIMIZAO E IMPLEMENTAO DE SEGURANA EM SISTEMAS OPERACIONAIS LINUX PARA SERVIDORES DE E-MAIL CORPORATIVO BASEADOS EM QMAIL.

ESTE TRABALHO FOI JULGADO ADEQUADO PARA A OBTENO DO GRAU DE BACHAREL EM CINCIA DA COMPUTAO E APROVADO EM SUA FORMA FINAL PELA DISCIPLINA DE TRABALHO DE CONCLUSO DE CURSO

BANCA EXAMINADORA:

__________________________________ PROFESSOR WILLIAM AUGUSTO R. DE SOUZA, M. SC.

__________________________________ PROFESSORA GRAZZIELA FIGUEREDO, M. SC.

__________________________________ PROFESSOR PROF. SANDOVAL GONALVES, M. SC.

5

AgradecimentosGostaria de agradecer a todas as pessoas que contribuiro direta ou indiretamente para este projeto e que continuaro contribuindo com idias, fora e dedicao. Ao meu orientador William Augusto R. de Souza que acreditou em mim quando ningum acreditava. Rafaela Haddad minha namorada pela dedicao e compreenso por todo este tempo. Ao Coordenador e Prof. Jos Xexo por sempre buscar o melhor esforo em cada aluno. A professora Grazziela Figueiredo por me dar a honra de participar da banca mesmo com os problemas existentes.

A todos os amigos e amigas que contriburam para o projeto trazendo sugestes, palavras de fora nos piores momentos. Tino Reichardt, contribuidor do projeto, que nos cedeu a licena de utilizao de seus softwares e Dan. J. Bernstein, desenvolvedor do qmail, sem eles este trabalho no seria possvel.

Aos professores Fernando Miranda, Nelson, que sempre acreditaram neste projeto deste o princpio.

6

7

SUMRIO

SUMRIO.........................................................................................................................6 ndice de Figuras ...............................................................................................................9 ndice de Tabelas .............................................................................................................10 Glossrio..........................................................................................................................11 1 - Introduo ..................................................................................................................13 1.1. Motivao .............................................................................................................15 1.2. Objetivos...............................................................................................................16 1.3. Etapas de desenvolvimento ..................................................................................17 2 Licena de Software .................................................................................................19 2.1. Definio ..............................................................................................................19 2.2. Software livre .......................................................................................................20 2.2.1. GNU Public License (GPL)...............................................................................21 2.3. Software proprietrio............................................................................................22 2.3.1. Creative Commons ............................................................................................23 2. 4. Comparao entre licenas ..................................................................................24 3 Sistema Operacional Linux .......................................................................................26 3.1. Histria e definio...............................................................................................26 3.2. Comparao entre Distribuies...........................................................................28 3.3. Distribuio Slackware.........................................................................................32 4 Servidores de e-mail cdigo aberto ...........................................................................34 4.1. Definio e Funcionamento..................................................................................34

8

4.2. Sendmail, Postfix e Qmail ....................................................................................38 5 Qmail .........................................................................................................................41 5.1. Definio ..............................................................................................................41 5.2. Segurana e Estrutura Hierrquica .......................................................................42 5.3. Licena de Uso .....................................................................................................46 5.4. Problemas existntes.............................................................................................46 6 - Otimizaes do Slackware para Qubit .......................................................................48 6.1. Pacotes utilizados e descartados ...........................................................................48 6.2. Empacotamento de softwares ...............................................................................50 6.3. Menus interativos de instalao............................................................................52 6.3.1. Particionamento .................................................................................................52 6.4. Kernel e Patches ...................................................................................................55 6.4.1. Patch para ReiserFS v.4.0..................................................................................55 6.4.2. Patch para BootSplash .......................................................................................58 7 - Hardening ...................................................................................................................60 7.1. Hardening de Sistema...........................................................................................61 7.2. Hardening de Servios..........................................................................................64 7.2.1. SSH e servios de acesso remoto .....................................................................64 8 - qmail e Patches...........................................................................................................68 8.1. Comparao entre verses e padres atuais .........................................................68 8.2. Medidas Anti-Spam..............................................................................................70 8.3. Medidas de Autenticao e Segurana .................................................................74 8.4. Medidas para testes de Bad Mail..........................................................................77 8.5. Medidas para melhorar mensagens de Status .......................................................78 8.6. Medidas para Logs de email.................................................................................80 8.7. Patch para BootSplash ..........................................................................................81 9 - Softwares Utilizados para servios ............................................................................82 9.1. EZmlm e EZmlm-idx............................................................................................82 9.2. Autoresponder ......................................................................................................82 9.3. Vpopmail ..............................................................................................................83 9.4. Courier-imap/imaps e Courierpassd .....................................................................84 9.5. Webmail................................................................................................................84 9.6. ClamAV................................................................................................................85 9.7. SpamAssassin .......................................................................................................85 10 - Padronizao ............................................................................................................86

9

10.1. Diretrios e Links ...............................................................................................86 10.2. Arquivos e Contedo ..........................................................................................87 11 - Concluso .................................................................................................................93 12 - Objetivos Futuros .....................................................................................................95 12 - Referncias Bibliogrficas .......................................................................................96

10

NDICE DE FIGURAS

Figura 1 - Funcionamento do Correio Eletrnico (WIKIPEDIA, 2007)...........................8 Figura 2 - Esquema de daemons do qmail (LIFE WITH QMAIL, 2007) .......................64 Figura 3 - Lista de Hard Disks gerada por Controladora .................................. .............64 Figura 4 - Particionamento Manual e Automtico ............................................................8 Figura 5 - Alguma coisa ..................................................................................................64 Figura 6 - Alguma coisa .................................. ...............................................................64

11

NDICE DE TABELAS

Tabela 1 - Comparao entre licenas de software (WIKIPEDIA, 2007).........................8 Tabela 2 - Aprovao de licenas por Organizaes (WIKIPEDIA, 2007) ...................15 Tabela 3 - Dispositivos e Softwares de Segurana (WIKIPEDIA, 2007) ......................15 Tabela 4 - Arquiteturas de Processadores Suportadas (WIKIPEDIA, 2007) .................15 Tabela 5 - Usurios do servidor qmail (LIFE WITH QMAIL, 2007) ............................15

12

GLOSSRIO

ACL - Access Control Lists ARPANet - Advanced Research Projects Agency Network BSD - Berkeley Software Distribution COPYRIGHT - Conjunto de direitos exclusivos que regulamentam o uso de uma ideia ou informao em particular DARPA - Defense Advanced Research Projects Agency EMAIL - Eletronic Mail FHS - File Hierarchy System FIREWALL - Dispositivo de uma rede de computadores que tem por funo regular o trfego entre redes distintas e impedir a transmisso e/ou recepo de dados nocivos ou no autorizados entre redes FSF - Free Software Foundation GNU - Anagrama recursivo para GNU is Not Unix GNU FDL - Free Document License GNU GPL - GNU Public License GNU LGPL - Light GNU Public License HA - High Availability HARDENING - Medidas de segurana tomadas no aumento da segurana de cdigo ou determinado ambiente de computao. IMAP - Internet Message Access Protocol

KERNEL - Cerne, o ncleo de um sistema operacional e representa a camada de software mais prxima ao hardware, sendo responsvel por gerenciar recursos do sistema operacional MINIX - Mini Unix MIT - Massachussets Institute of Technology MTA - Mail Transfer Agent MTU - Mail Transfer User MUA Mail User Agent MX Mail Exchanger PATCH - Cdigos auxiliares incluidos no cdigo fonte para implementao de funcionalidades ou correo de erros POP - Post Office Protocol SELINUX - Security Enhanced Linux SMTP - Simple Mail Transfer Protocol SSL - Secure Sockets Layer TCP/IP - Transfer Control Protocol / Internet Protocol TLS - Transport Layer Security UCLA - University of California Los Angeles VPN - Virtual Private Network

1 - INTRODUO

A Internet tem revolucionado o mundo dos computadores e da comunicao como nenhuma outra inveno jamais conseguiu, ligando usurios de todas as partes da Terra no clique de um boto. Invenes importantes como o telgrafo, telefone, fax e outras serviram de base para preparao do cenrio atual de super integrao e comunicao existente.

Os primeiros registros de interaes sociais que poderiam ser realizados atravs de redes de computadores que se tem notcia foram uma srie de memorandos escritos por J.C.R. Licklider, do MIT (Massachussets Institute of Technology), em agosto de 1962. Esta srie de memorandos previa a existncia de vrios computadores interconectados globalmente de forma que todos poderiam acessar dados e programas de qualquer lugar rapidamente. Essencialmente o conceito muito parecido com o que temos hoje com a Internet. Licklinder foi o primeiro gerente do programa de

pesquisas de computador do DARPA, comeando em outubro de 1962. O primeiro trabalho sobre a teoria de troca de pacotes existente foi publicado por Leonard

Kleinrock, do MIT, em julho de 1961. Leonard Kleinrock comeava assim a convencer a todos da possibilidade terica das comunicaes usando pacotes ao invs de circuitos o que representou um grande passo para a criao das redes de computadores atuais. Outro grande passo foi fazer os computadores destas redes conversarem entre si.

Foi no DARPA que nasceram os conceitos de redes de computadores atuais que viriam a formar a ARPANET, em 1967, rede esta precursora da Internet.. A ARPANET foi desenvolvida por instituies militares americanas para dinamizar as

comunicaes entre postos, portanto demorou pouco tempo para que surgisse a primeira troca de mensagens via rede, troca esta que s foi possvel depois do desenvolvimento do primeiro Processador de Interface de Mensagens (IMP) pelo DARPA, em 1968. Aps um ms de implementao do primeiro IMP na UCLA foi feita a primeira troca de mensagens entre servidores do DARPA e o SRI (servidor localizado na UCLA). Nascia ai a era da comunicao digital, e por assim dizer os servios de troca de mensagens conhecidos hoje como e-mail.

Atualmente a troca de mensagem via servidores de e-mail so responsveis por 50% do trfego de internet de todo o meio corporativo segundo dados do Wikipedia, (http://en.wikipedia.org/wiki/Email#Origin), e seu consumo cresce a cada dia devido a sua rpida popularizao, facilidade de uso e pragas virtuais decorrentes disto. Devido a este fato importante que os sistemas funcionem de forma a possurem performance e segurana para atender a demanda do servio na Internet.

1.1. MotivaoAtualmente existem diversas solues para e-mail corporativo desenvolvidas por vrios fabricantes internacionalmente conhecidos como Microsoft (Exchange Server), IBM (Lotus Notes Workgroup), Critical Path, entre outras. Cada uma dessas solues possui um conjunto de funcionalidades anlogas porm condizentes diretamente a poltica de servios da empresa. importante frisar que todas as solues supracitadas recaem sobre a licena de software proprietrio, portanto sua utilizao deve ser de acordo as restries tcnicas e de custo impostas por cada desenvolvedor.

Para aumentar a concorrncia e expandir o mercado no que diz respeito s tecnologias de servidores de e-mail e no que tange performance e custo, surgiram diversas outras solues livres, cada uma avaliada e testada pela grande comunidade de software livre. A maior parte possui implementaes prprias em ambientes Linux previamente desenvolvidos e padronizados transformando portanto sistemas complicados e complexos em sistemas intuitivos e de fcil instalao e adoo no meio corporativo. Porm a quantidade de distribuies Linux voltadas para o campo de servidores de e-mail diretamente relacionada funcionalidades, praticidade e facilidade de configurao do MTA (Mail Transfer Agent) ou cliente de e-mail escolhido, sendo dele Postfix, Sendmail, entre outros. Sendo assim cada distribuio Linux, embora use o mesmo MTA como foco, implementada e desenvolvida de forma totalmente diferente e muitas vezes incompatvel com outros sistemas, terminando por existirem diversas solues diferentes para um mesmo problema. Isto gera um aumento no esforo de suporte ao ambiente criado bem como inconsistncia de procedimentos.

Embora existam solues anlogas no inexiste atualmente uma distribuio Linux para servidores de e-mail voltada totalmente para o MTA qmail. Um dos fatos que contribuem para isto a extrema complexidade quando da implementao de um servidor completo qmail e tambm na existncia de vrios tutoriais completamente incompatveis entre si, gerando inclusive dvidas quanto a sua implementao, j que cada administrador implementa apenas os recursos pertinentes a sua rede esquecendo muitas vezes que o sistema deve ser escalar permitindo assim uma utilizao mais dinmica e extensa. Outro fato o cdigo do qmail no ser intensamente mantido por seu criador o matemtico Dan. J. Bernstein, desvantagem esta totalmente suprida pela grande comunidade de software livre. Porm esta comunidade gera outros problemas como desenvolver ferramentas diferentes para resoluo de um mesmo problema gerando assim uma gama de aplicaes anlogas, aumentando o trabalho do administrador para padronizao e criao de uma soluo de e-mail concisa e estvel.

1.2. ObjetivosEste trabalho uma extenso dos esforos da comunidade de cdigo aberto em atuao na Internet no desenvolvimento de um sistema de e-mail padronizado, eficiente e seguro. A proposta desenvolver uma sistema operacional Linux baseado na Distribuio Slackware 12.0 com foco na criao, instalao, configurao e implementao de uma soluo completa de servio de e-mail baseado em qmail, MTA desenvolvido pelo matemtico Dan J. Bernstein como alternativa rpida e segura ao famoso MTA Sendmail desenvolvido por Eric Allman. Este sistema ser

desenvolvido de forma a aproximar o usurio leigo ao mundo dos servidores de e-mail de forma a transformar o processo de implementao em um processo mais intuitivo e totalmente padronizado.

O desenvolvimento deste projeto baseia-se no fato de que no existe atualmente uma distribuio totalmente voltada para este servidor especfico, como existem para outros servidores como postfix e sendmail. Sero implementados os mais novos conceitos de configurao de servidores seguros utilizando otimizao de cdigo via patches, configuraes, boas prticas de configurao de servios e hardening de sistema.

Este projeto visa dinamizar e facilitar a implementao e configurao de um servidor de e-mail qmail seguindo os padres de utilizao corporativa atual, reduzindo o tempo mdio de tais operaes de 48 horas para 1,5 hora mximo, implementando um sistema totalmente integrado com softwares recomendados atualmente como antivrus, anti-spams, e polticas de segurana de sistema e servios.

1.3. Etapas de desenvolvimentoForam realizadas pesquisas sobre os principais MTAs de cdigo aberto utilizados atualmente em servios de e-mail. As pesquisas levaram em conta componentes estruturais, funcionais e de segurana na avaliao das diferenas entre cada um dos MTAs utilizados como base na escolha do MTA abordado. So traados vrios paralelos pertinentes a segurana, estabilidade, funcionalidade, freqncia de

atualizaes oficiais e da comunidade de cdigo aberto, instalao, configurao e uso, assim como estudos de casos reais de utilizao no meio corporativo.

Foram realizadas tambm pesquisas de intuitividade quanto a instalao do sistema, e funcionalidades pertinentes a este fim bem como extensa pesquisa sobre hardening (implementaes de segurana) de sistema operacional Linux e servios de e-mail qmail na criao de um servio seguro.

2 LICENA DE SOFTWARE

2.1. DefinioUma licena de software compreende permisses, direitos e restries A um determinado software, sendo ele apenas um componente ou um programa completo. A utilizao de um software sem obedecer as restries impostas por sua licena podem constituir em uma infrao dos direitos exclusivos do desenvolvedor do software sobre copyright ou, ocasionalmente , lei de patentes permitindo ao dono do software licenciado direitos para processar o usurio que a infringiu.

Sob a licena de software, ela permite a utilizao do software desde que esta esteja de acordo com os termos da licena. Se h uma brecha na licena, dependendo do tipo, pode terminar por conceder direitos ao proprietrio da licena do software processar quem a infringiu.

Um desenvolvedor de software pode oferecer uma licena unilateral (sem dar ao licenciado oportunidades para renegociao de termos mais favorveis), ou mesmo

como parte de um acordo de licena de software com terceiros. Virtualmente todo software proprietrio produzido em larga escala vendido sob alguma forma de licena. Os termos de tais licenas normalmente so negociados entre as partes, licenciador e licenciado.

Em adio a garantia de direitos e imposio de restries utilizao do software, as licenas tipicamente contm procedimentos que denotam confiabilidade e responsabilidade entre as partes. Em softwares corporativos e softwares de transao comercial so normalmente negociados por equipes especialistas em licenas de software.

2.2. Software LivreSo denominados softwares livres, ou de domnio pblico, os softwares cuja licena permite qualquer tipo de uso, alterao, cpia, venda, e distribuio desejada pelo usurio em relao a seu cdigo-fonte. Para que o cdigo fonte possa ser alterado e aperfeioado imperativo que ele esteja disponvel para download sem qualquer restrio e de forma completa. Se um programa livre ele pode ser facilmente implementado em um sistema operacional tambm livre.

importante enfatizar que software livre no sinnimo de software gratuito pois a liberdade de distribuir, alterar e copiar independe da gratuidade. Existem softwares que podem ser obtidos na Internet de forma gratuita mas no podem ser alterados ou redistribudos pois muitas vezes seu cdigo-fonte fechado ou recai sobre determinada licena que impede est operao.

Atualmente existem diversos tipos de licenas de software livre com as mais variadas permisses e restries. A licena escolhida para este projeto a GPL, ou GNU Public License, pela liberdade que apresenta em relao a cpia, alterao e redistribuio de cdigo nela registrado como explicado adiante.

2.2.1. GNU Public License (GPL)A GNU Public License, ou simplesmente GPL, a licena de software livre criada e idealizada por Richard Stallman, fundador da Free Software Foundation (FSF), no final da dcada de 1980. A GPL a licena mais utilizada por projetos de software livre no mundo. Ela baseia-se em 4 premissas bsicas:

Liberdade de executar um programa para qualquer propsito (Liberdade n 0).

Liberdade de estudar como o programa funciona e adapt-lo para suas necessidades (liberdade n 1). O acesso ao cdigo-fonte um prrequisito para estar liberdade.

Liberdade de distribuir cpias de modo que o usurio possa ajudar o seu prximo (liberdade n2).

Liberdade de aperfeioar o programa, a liberar os seus aperfeioamentos, de modo que toda a comunidade se beneficie deles (liberdade n 3). O acesso ao cdigo-fonte um pr-requisito para estar liberdade.

Pelos termos da licena GNU podemos escrever, alterar, reenviar, trocar e vender quaisquer alteraes feitas no cdigo-fonte pois ele de utilizao livre.

A licena GPL tambm possui outras duas sub-licenas: GNU FDL (GNU Free Document License) e a GNU LGPL (GNU Light Public License), que compreendem em licenas para documentao livre, e uma verso mais resumida e simples da GPL padro para o desenvolvimento de drivers, bibliotecas e pequenos mdulos ou addons, respectivamente.

Atualmente todo e qualquer software desenvolvido ligado a comunidade de software e ao Free Software Foundation so licenciados sob a GPL.

2.3. Software ProprietrioSoftwares proprietrios so aqueles cuja cpia, redistribuio ou modificao esto limitadas ou impossibilitadas pelas restries de sua licena. Para utilizar, copiar, alterar cdigo ou redistribuir, deve-se solicitar permisso ao desenvolvedor ou empresa que detm os direitos de propriedade do software requerido, ou pagar para faz-lo.

Algumas licenas de software proprietrio possuem cdigo livre que pode ser utilizado e alterado apenas para uso prprio mas impe restries quanto a redistribuio deste cdigo modificado. Outras licenas permitem a utilizao de determinado software de modo ilimitado ou temporrio sem oferecer o cdigo-fonte utilizado para compil-lo. Existem ainda softwares cujos cdigos-fontes no so distribudos, so apenas executados via software de instalao e ao mesmo tempo so

pagos, como o caso de muitos sistemas operacionais utilizados no mercado corporativo ou programas de cunho comercial. As restries e permisses de cada licena variam para cada empresa e proprietrio de software.

2.3.1. Creative CommonsA licena Creative Commons permite aos proprietrios de software garantir em parte ou totalmente seus direitos de software ao pblico enquanto retm outros, atravs de uma variedade de licenas e esquemas de contrato incluindo softwares de domnio pblico ou termos de licena de contedo aberto. O objetivo deste tipo de licena proprietria evitar problemas com a lei de copyright no que tange o compartilhamento da informao.

O projeto Creative Commons prov vrios tipos de licena gratuitas as quais os proprietrios dos direitos de software possam utilizar no lanamento de seus trabalhos na rede. Ao mesmo tempo que protege a propriedade intelectual de seus proprietrios, evita problemas com a lei e permite, dentro das restries impostas pelo proprietrio, sua redistribuio, alterao e uso ao pblico.

Exemplos de projetos que utilizam esta licena so Wikimedia (Wikimedia, 2007) , Public Library of Science, Jurispedia, entre outros.

2.4. Comparao entre licenasA tabela seguinte compara vrias caractersticas de cada uma das licenas , como um guia para os termos que cada uma das licenas contm:Link de cdigo com licena diferente ? Sim Sim Sim ? Sim Sim Sim ? ? ? Sim No Sim ? ? ? ? Sim Sim ? ? ? ? ? No ? Sim Sim Sim ? ? ? Mudanas sob licenas diferentes ? Sim No Com restries ? Sim Sim ? No ? ? Sim No No ? ? ? ? Sim No ? ? ? ? ? No ? No Sim Sim ? ? ?

Licena Academic Free License Apache License Apple Public Source License Artistic License Berkeley Database License BSD license Boost license Common Development and Distribution License Common Public License Cryptix General License Eclipse Public License Educational Community License GNU General Public License GNU Lesser General Public License Hacktivismo Enhanced-Source Software License Agreement IBM Public License Intel Open Source License LaTeX Project Public License MIT license Mozilla Public License Netscape Public License Open Software License OpenSSL license PHP License Python Software Foundation License Q Public License Sun Industry Standards Source License Sun Public License W3C Software Notice and License X11 license XFree86 1.1 License zlib/libpng license Zope Public License

Autor ? Apache Software Foundation Apple Computer ? ? ? ? Sun Microsystems ? ? Eclipse Foundation ? Free Software Foundation Free Software Foundation Hacktivismo/Cult of the Dead Cow IBM Intel Corporation LaTeX project ? Mozilla Foundation Netscape ? OpenSSL Project PHP Group Python Software Foundation Trolltech Sun Microsystems Sun Microsystems ? ? ? ? ?

ltima Verso ? 2 2 2 ? ? ? 1 ? ? 1 1 3 3 ? ? ? 1.3c ? 1.1 1.1 ? ? 3.01 2 ? ? ? ? ? ? ? ?

Data de Publicao ? 2004 6-Aug-03 ? ? ? ? ? ? ? ? ? Jun-07 Jun-07 26-Nov-02 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

Tabela 1 Comparao entre licenas de software (WIKIPEDIA, 2007)

A tabela abaixo lista para cada licena quais organizaes as aprovaram como open source (cdigo livre) e como est organizaes as categorizam. Estas organizaes aprovam normalmente verses especficas de licenas.

Licence and specific version Academic Free License Apache License Apple Public Source License version 1.x Apple Public Source License version 2.0 Artistic License Clarified Artistic License Berkeley Database License BSD license Common Development and Distribution License Common Public License Cryptix General License Eclipse Public License Educational Community License GNU General Public License GNU Lesser General Public License Hacktivismo Enhanced-Source Software License Agreement IBM Public License Intel Open Source License LaTeX Project Public License License of Python MIT license Mozilla Public License Netscape Public License Open Software License OpenSSL license PHP License Q Public License Sun Industry Standards Source License Sun Public License Sybase Open Watcom Public License W3C Software Notice and License XFree86 1.1 License zlib/libpng license Zope Public License version 1.0 Zope Public License version 2.0

FSF approval Sim Sim No Yes No Sim Sim Sim Sim Sim Sim Sim ? Sim Sim No Sim Sim Sim Sim Sim Sim Sim Sim Sim Sim Sim Sim Sim ? Sim No Sim Sim Sim

OSI approval Sim Sim Sim Sim Sim Sim Sim Sim Sim Sim No Sim Sim Sim Sim No Sim Sim No Sim Sim Sim No Sim No Sim Sim Sim Sim Sim Sim No Sim ? Sim

Tabela 2 Aprovao de licenas por Organizaes (WIKIPEDIA, 2007)

3 SISTEMA OPERACIONAL LINUX

3.1. Histria e DefinioEm 1991 praticamente todas as universidades do mundo utilizavam algum tipo de Unix como sistema operacional acadmico nos quais seus alunos desenvolviam todo tipo de trabalho de pesquisa . Em sua grande maioria era utilizado o Unix BSD (Desenvolvido pela Berkeley). Como sua licena era muito cara para o meio acadmico, as universidades passaram a adotar uma verso mais simples e com menos recursos chamada Minix, um clone de cdigo aberto do Unix desenvolvido especialmente para suprir sua falta de verba. Como todo clone o Minix carecia de recursos bsicos, utilizado portanto vastamente apenas como sistema base para projetos e trabalhos acadmicos.

Um aluno da Universidade de Helsink na Finlndia, Linus Torvalds, no concordava com esta viso e queria oferecer mais funcionalidades ao Minix fazendo-o to completo quanto seu similar corporativo. Ele iniciou seu projeto em meados dos anos 1990 atravs de uma mensagem enviada s listas de e-mail da poca convocando

programadores a se juntarem a ele no desenvolvimento de um sistema completo e totalmente gratuito que pudesse ser distribudo sem custos e de cdigo livre.

Por definio o sistema operacional Linux nada mais do que um clone cdigo aberto dos sistemas Unix da poca possuindo kernel prprio desenvolvido por Linus Torvalds em adio aos programas j existentes da FSF (Free Software Foudation) fundada por Richard Stallman.

Devido a sua rpida adoo pelo mercado corporativo e domstico, existem atualmente diversas distribuies diferentes em funcionalidades e foco no mercado. Exemplos disso so as seguintes distribuies: Slackware (www.slackware.org) : Desenvolvida por Patrick

Volkerding em Julho de 1993. considerada a mais antiga e primeira distribuio Linux completa. Debian (www.debian.org) : Distribuio mais utilizada por

desenvolvedores e acadmicos de Linux pois segue completamente a filosofia da GNU da Free Software Foundation, totalmente licenciada pela GPL, ou seja, gratuito e de cdigo aberto. Redhat (www.redhat.com) : Distribuio Linux criada para o mercado corporativo. Muitos de seus softwares so gratuitos porm praticamente tudo que diz respeito ao mercado corporativo restrito e de cdigo fechado, sendo assim pago. A Redhat hoje considerada um gigante no meio corporativo Linux.

Conectiva ( www.conectiva.com.br ) : Vertente brasileira do Redhat alterado para uso nacional. considerada a primeira distribuio Linux brasileira. Hoje no existe mais e foi integrada distribuio Mandrake formando assim uma nova distribuio chamada Mandriva. Mandriva ( www.mandriva.com ) : Anteriormente conhecido como Linux Mandrake, foi formada pela unio da Mandrake com a Conectiva. atualmente uma das distribuies mais utilizadas no mercado europeu, junto com a Suse. Suse ( www.novell.com/linux ) : Criada por uma das maiores empresas de TI do mundo, a Novell Networks, sendo atualmente a distribuio mais utilizada no mercado europeu.

3.2. Comparao entre DistribuiesExistem atualmente, entre distribuies corporativas e suas dissidncias, cerca de 90 distribuies famosas largamente utilizadas no mundo. Obviamente existem outras dezenas dissidentes destas e portanto um pouco menos conhecidas. A escolha de determinada distribuio, muitas vezes chamada de flavor, ou sabor, depende da aptido e gosto do usurio com o sistema em questo. Normalmente usurios mais experientes preferem distribuies mais robustas e experientes com um maior nmero de casos de sucesso como Slackware, Debian e Redhat, distribuies estas com maior respaldo da comunidade de software livre, ou de seus fabricantes. Usurios de entrada ou inexperientes preferem distribuies de escopo tcnico menor e mais intuitivas como CentOS, Suse e Mandriva, por serem mais fceis de utilizar.

Esta escolha esta diretamente ligada as seguintes caractersticas: Praticidade : importante quando da utilizao, manuteno e suporte da distribuio. Operaes que podem levar horas quando a compilao de cdigo eminente podem ser reduzidas para minutos no caso da existncia de ferramentas dinmicas e de fcil uso diminuindo assim o tempo necessrio com suporte e tambm a curva de aprendizado no treinamento de um profissional da rea. Intuitividade : importante para acelerar tarefas como manuteno do sistema e principalmente mais importante para o usurio final. Sendo este um usurio no muito tcnico ter um sistema intuitivo, com softwares facilmente localizados no ambiente de janelas ou linha de comando, primordial para um bom aproveitamento empresarial ou domstico sem a necessidade de auxlio profissional do suporte. Segurana : Este o item mais importante na escolha de uma distribuio para servidores. extremamente importante uma vez que o Linux considerado o sistema operacional mais adotado no meio corporativo para servios crticos como High Availability, Firewall, VPN, E-mail entre outros. Deve-se verificar a freqncia de correes de erros bem como atualizaes normais do sistema por meio de pacotes disponibilizados pelo desenvolvedor oficial. Funcionalidades : Devem possuir suporte aos mais novos sistemas de arquivos, algoritmos e ferramentas do mercado. Devem suportar diversos tipos de arquitetura de processadores diferentes para uma melhor adoo no mercado.

Como vimos a utilizao baseada no gosto e necessidade de cada administrador, bem como o hardware disponvel para utilizao.

Outro paralelo de comparao necessrio em relao aos dispositivos de segurana existentes em cada distribuio. Cada distribuio depende de um determinado escopo para que suas funcionalidades sejam definidas, por exemplo, importante para o Linux Redhat suportar diversos sistemas de arquivo e arquiteturas de processadores pois a distribuio mais largamente utilizada no meio corporativo o qual quase sempre faz parte de um cenrio totalmente heterogneo, mas em relao a segurana no necessrio grade suporte, apenas os bsicos como ACLs (Access Lists ou Listas de Acesso) e o pacote SELinux entre outras medidas externas para um melhor e seguro funcionamento do sistema. Por outro lado sistemas como Slackware, Gentoo, Engarde e Backtrace so praticamente todos orientados algum campo de segurana e so as distribuies mais utilizadas para este fim, necessitando assim de mais recursos neste quesito. Podemos portanto caracterizar as distribuies quanto a este quesito na tabela a seguir:

Distribuio CentOS Linux Debian Linux Fedora Linux Gentoo Linux Red Hat Enterprise Linux Mandriva Linux SUSE Linux Slackware Linux

AppArmor No No No No No No Sim Sim

BGCC No No No Sim No No No No

Exec Shield Sim Opcional Sim Sim Sim Sim No Opcional

GrSecurity No Opcional No Opcional No No No No

PaX No No No Sim No No No No

Rsback No No No No No No No No

SELinux Sim Opcional Sim Opcional Sim Sim No Sim

Systrace No No No Opcional No No No Opcional

RSBAC No No No Opcional No No No No

Tabela 3 Dispositivos e Softwares de Segurana (WIKIPEDIA, 2007)

Na tabela supracitada no foram descritos os dispositivos de segurana da distribuio Qubit Linux, escopo deste projeto, pois ser discutida a fundo em outro item.

No item funcionalidades existe outro fator, j supracitado como exemplo, importante na escolha de uma distribuio que a quantidade de sistemas de arquivos suportados pelo sistema. Geralmente distribuies de escopo corporativo possuem uma maior desenvoltura neste aspecto visto atenderem os mais heterogneos ambientes em diversos tipos de empresa. J distribuies no muito conhecidas possuem um foco menor neste quesito, suportando menos sistemas, na verdade apenas os mais utilizados no escopo de seu funcionamento. Em geral os sistemas de arquivos no suportados por padro em algumas delas podem ser includos por meio de cdigo adicional, mais conhecido como patches, que fornecem mais funcionalidades, estes geralmente aplicados sobre o kernel do linux. Abaixo segue uma tabela comparativa de suporte aos mais variados tipos de sistema de arquivos em alguns sistemas linux mais conhecidos.

Distribuio CentOS Linux Debian Linux Fedora Linux Gentoo Linux Red Hat Enterprise Linux Mandriva Linux SUSE Linux Slackware Linux

x86 Sim Sim Sim Sim Sim Sim Sim Sim

x8664 Sim Sim Sim Sim Sim Sim Sim No

IA64 Sim Sim No Sim Sim No Sim No

ppc No Sim Sim Sim Sim Sim Sim No

ppc64 No No No Sim No No No No

sparc32 No Sim No No No No No No

sparc64 No Sim No Sim No No No No

s390 Sim Sim No Sim Sim No Sim Sim

s390x Sim Sim No Sim Sim No Sim No

alpha Sim Sim No Sim No No No No

Tabela 3 Arquiteturas de Processadores Suportadas (WIKIPEDIA, 2007)

3.3. Distribuio SlackwareO Linux Slackware um sistema Linux avanado desenvolvido em 1993 pelo programador Patrick Volkerding com o intuito de ter usabilidade e estabilidade como prioridade. Ele inclui as mais novas verses dos mais novos softwares GNU existentes, mantendo o tradicional senso de segurana e estabilidade do sistema, provendo facilidade de uso e flexibilidade.

Desde sua primeira verso em 1993, sua proposta de produzir um sistema mais parecido com o Unix no que tange simplicidade, segurana e desempenho, ele foi desenvolvido primeiramente seguindo os padres dos Unixes BSD utilizados em Berkeley como OpenBSD, FreeBSD, e NetBSD. O Slackware mantm suporte em relao aos aspectos mais atuais de sistemas linux como FHS (File Hierarchy Standard) com diretrios padronizados e estruturados, bem como ao padro POSIX, largamente utilizado no mundo Unix e Linux.

O Slackware um sistema linux completo multitarefa na arquitetura 32 bits , com suporte a outras arquiteturas como 64 bits. Ele baseado no kernel verso 2.4, desenvolvido por Linus Torvalds, com suporte tambm a verses 2.6 atuais. Todas as verses de kernel baseadas na biblioteca GNU C verso 2.3.4 (libc6). Sua instalao intuitiva e simples contando com telas de ajuda ao logo do processo. Ele possui extensa documentao no site oficial (www.slackware.org) e tambm em milhares de fruns de discusso associados. O sistema Slackware pode rodar em arquiteturas 486 em mquinas x86 como P3, P4, Athlon, Duron, entre outras.

O Slackware a distribuio escolhida por este projeto pois como apia seu funcionamento em flexibilidade, simplicidade e estabilidade, nos fornece condies

favorveis para desenvolv-lo aplicando sua gama de funcionalidades para um ambiente corporativo de servidores, suportando o escopo atual de um servidor de email estvel, flexvel e seguro. Outro fator que influenciou em nossa escolha foi o fato do Slackware Linux ser a distribuio mais imples e flexvel disponvel permitindonos a alter-la basicamente reconfigurando scripts simples de inicializao e instalao, bem como criar nossos prprios. Ela nos permite uma escolha bem mais simples de pacotes utilizados e descartados pelo sistema simplesmente apagando-os.

4 SERVIDORES DE E-MAIL CDIGO ABERTO

4.1. Definio e FuncionamentoO servidor de e-mail, mais conhecido como mail exchanger (MX), no contexto de um servidor de nomes de domnio um software de computador instalado em um determinado host capaz de transferir mensagens eletrnicas entre dois computadores conectados a uma rede.

Para que dois computadores troquem mensagens entre eles ambos deve estar conectados uma rede e possuir algum mail transfer agent (MTA). MTAs so softwares que se conectam em determinado servidor de e-mail de modo a enviarem suas mensagens, e tambm so responsveis por receber todas as mensagens armazenadas em suas caixas postais eletrnicas neste servidor conectando-se ao mesmo servidor, ou servidor diferente, para resgat-las.

Como em toda conexo baseada em protocolos da pilha TCP/IP, a conexo do MTA com o MX tem seu controle baseado no par IP:Socket, independente do servio

utilizado pelo servidor, que pode variar de porta. Existem atualmente vrios protocolos que participam do funcionamento de um servidor de e-mail atual. So eles: SMTP ( Simple Mail Transfer Protocol ) : Servio da camada 3 do modelo OSI utilizado para troca de mensagens entre hosts definido pela RFC 821 e estendido pela RFC 1123. Atualmente utilizado o ESMTP definido pela RFC 2821 que nada mais que o SMTP estendido. Atualmente o ESMTP o protocolo para troca de mensagens mais utilizado na Internet. O servidor SMTP aguarda conexes TCP de clientes MUA na porta 25. POP ( Post Office Protocol ) : Servio da camada 3 do modelo OSI utilizado para armazenamento e resgate de mensagens no servidor via clientes MUA. Definido inicialmente pela RFC 918 e atualizado para RFC 1939. O POP aguarda por conexes TCP na porta 110 no servidor. Atualmente est na verso 3. IMAP ( Internet Message Access Protocol ) : Servio da camada 3 do modelo OSI para armazenamento e resgate de e-mails no servidor,

definido pela RFC 1064 e atualizado para RFC 3501. Ele considerado uma evoluo do protocolo POP j conhecido, pois fornece vrias outras funcionalidades no existentes neste. Seu servidor aguarda conexes TCP de clientes MUA na porta 143.

Podemos definir o funcionamento de troca de mensagens padro com a figura a seguir:

Figura 1 Funcionamento do Correio Eletrnico (WIKIPEDIA, 2007) O usurio remetente da mensagem utiliza um MUA de sua escolha, como Outlook, Thunderbird, entre outros, para conectar-se ao MTA que possui sua prpria caixa postal eletrnica, caracterizado na figura pelo Servidor A, via protocolo SMTP na porta 25. Este MTA por sua vez verifica se a caixa do usurio remente existe. Caso a conta inexista o MTA cancela a operao enviando ao MUA do usurio uma mensagem de erro. Caso a conta exista o MTA faz consultas ao seu DNS para encontrar que MTA no mundo contm a caixa de e-mail do destinatrio. Uma vez encontrado o destinatrio o Servidor A acessa o MTA remoto, caracterizado na figura pelo Servidor B, tambm com uma conexo TCP na porta 25 do Servidor B. Quando o MTA Servidor B recebe esta conexo ele verifica se a conta do usurio remetente existe, caso positivo a mensagem entregue, caso negativo o Servidor A recebe a resposta de que a conta destinatria no existe, mensagem esta retransmitida ao MUA rementente.

O resgate das mensagens contidas num servidor de e-mail pode acontecer utilizando dois protocolos diferentes, SMTP ou IMAP. Quando utilizado o protocolo POP, o cliente MUA que requer o resgate das mensagens conecta no MTA que possui sua conta na porta 110 via TCP. O MTA verifica se a conta do usurio existe, negativo

o MUA emissor recebe uma mensagem de que a conta inexiste. Caso positivo o MTA destino valida usurio e senha configurados no MUA e compara com as configuraes de sua conta. Caso usurio e conta existam e sejam vlidos o servidor lista as mensagens existentes. Caso haja alguma o MUA cliente as resgata para si.

O procedimento acima exatamente igual em teoria ao protocolo IMAP com uma nica diferena, em um servidor IMAP normalmente as imagens permanecem no servidor por padro. As nicas informaes resgatadas pelo cliente so os ndices da caixa postal, ou seja, os nomes de assuntos das mensagens existentes e nada mais. Caso o usurio tenha necessidade de ler alguma mensagem ela resgatada no momento em que ele a solicita dando um clique simples sob o nome de assunto da mensagem.

Atualmente um servidor de e-mails corporativo no possui apenas os servios bsicos para troca de mensagens. A medida que a demanda por funcionalidades aumenta, a necessidade por outros tipos de servios se justifica. Servios como webmails que permitem aos clientes acesso a suas mensagens de qualquer lugar do mundo simplesmente atravs da utilizao de qualquer computador conectado a internet via navegador web como Internet Explorer, Mozila Firefox, entre outros. Os servios de webmail por si s possuem funcionamento bem simples porm necessitam de uma certa infra-estrutura para que funcionem tais como servidores de pginas, suporte a linguagens web interpretadas e , dependendo da complexidade do software, bancos de dados para armazenamento de mensagens e logs dos servios.

4.2. Sendmail, Postfix e qmailEm 1991 praticamente todas as empresas que possuiam um servidor de e-mail para troca de mensagens utilizava o Sendmail. O Servidor Sendmail foi desenvolvido por Eric Allman em 1971 que tinha como objetivo padronizar todos os MTAs existentes em apenas um. Atualmente o servidor Sendmail ainda o mais utilizado principalmente por ser o mais antigo e maduro servidor existentes porm sua utilizao decaiu muito pelo advento da criao de vrios outros servidores de e-mail mais modernos. O Sendmail possuia diversos problemas estruturais, primeiramente ele foi feito para um ambiente de interconexo de redes quando a premissa bsica era a possibilidade de troca de mensagens e no a segurana do meio em s visto que este meio era muito caro impossibilitando sua utilizao pela maior parte da populao. Com este fato apareceram diversos problemas de segurana provenientes de erros no cdigo e tambm da total falta de adequao ao paradigma da segurana.

Seus principais erros eram em relao ao cdigo, muito em parte pela falta de projeto e padronizao no desenvolvimento de qualquer software existentes na poca o que tambm trazia outro problema, o tempo de manuteno do software que era constantemente ultrapassado. A medida que os erros no daemon Sendmail iam aparecendo era necessrio um suporte eficaz para sua correo, quase sempre acompanhada de patches e consecutiva recompilao do cdigo onde era necessrio apenas um erro de uma linha de comando para que est compilao no fosse executada com sucesso.

Suas caixas postais de usurios funcionavam no sistema Maildir padro onde cada mensagem ficava no diretrio pessoal do usurio, e cada um dos usurios deveria

existir no servidor, fazendo com que se houvesse a necessidade de um servidor para 5.000 contas, deveriam existir 5.000 usurios, um para cada conta, configurado corretamente no sistema de e-mail. No havia ainda gerenciadores de domnios e contas virtuais obrigando assim que cada usurio de e-mail tambm fosse um usurio do sistema.

Outro erro crucial do sendmail era que seu daemon principal, como chamado o processo principal de um software servidor, era executado pelo usurio root, administrador do sistema Linux, portanto qualquer falha explorada por um invasor em potencial era explorada sobre este usurio, sendo ele o usurio administrador caso o atacante conseguisse invadir o servidor por meio de alguma falha de buffer overflow no servidor ele entraria com privilgios de root. Alm do usurio root alguns programas tambm eram utilizados com permisses SUID o que permitia que usurios normais do sistema executassem programas com privilgios de root. Esta falha no era apenas de segurana, era tambm estrutural uma vez que bastava apenas um erro no daemon principal para que o sistema inteiro ficasse inoperante. A configurao do servidor tambm era baseada apenas em um arquivo, extremamente complexo e no intuitivo, onde eram feitas todas as operaes de configurao bsicas bem como whitelists, blacklists e outras protees ao servidor. Se este arquivo fosse comprometido por erros no sistema de arquivo o servio inteiro era comprometido. importante frisar que nesta poca os sistemas de arquivos Journaling (sistemas de arquivo com gravao e leitura serializada, evitando assim fragmentao) ainda

estavam em fase de projeto. Todo sistema de arquivos no journaling mais propcio a falhas, sendo estas mais difceis de corrigir levando muitas vezes a um problema do servidor mesmo ele no sendo gerado pelo servio de email em s.

O Sendmail foi feito em uma poca onde a segurana no era to essencial, e este era exatamente seu ponto fraco. O sendmail no conseguiu acompanhar as rpidas e frequentes mudanas nos paradigmas de segurana e novos servios necessrios ao mercado corporativo, contudo continuava a ser o servidor mais completo do mercado.

Alguns anos depois foi criada outra alternativa ao Sendmail, o Postfix. Patriocinado pela IBM e desenvolvido por Wietse Venema o Postfix foi criado com o objetivo de ser rpido, fcil de administrar e seguro. Ele possuia suporte completo ao Sendmail pois suas bases eram as mesmas. Houve um grande avano na instalao e configurao que ficaram bem mais intuitivas e simples. Assim como o Sendmail ele tambm era gratuito, lanado sob a licena GPL. Porm ele tambm possuia diversos problemas. O principal que mantinha a mesma base do sendmail o que o tornava um pouco antigo para algumas configuraes. Outro problema eram as constantes atualizaes de segurana pois sofria diversas invases decorrentes de erros gerados por cdigo mal feito. Estas constantes atualizaes tambm necessitavam de recompilao de seu cdigo fonte o que forava a indisponibilidade do servio para que sua manuteno fosse executada. Embora suas atualizaes de segurana fossem lanadas constantemente o Postfix possuia o mesmo problema principal de executar seu nico daemon padro com privilgios de usurio root o que trazia os mesmo problemas gerados por seu servidor antecessor.

Finalmente em 1991 foi criado o qmail desenvolvido por Dan J. Berstein como uma altenativa totalmente segura, rpido e de fcil administrao, conforme discutido no captulo seguinte.

5 QMAIL

5.1. DefinioO servidor qmail, projetado e desenvolvido em 1996 pelo pesquisador e matemtico Dan J. Bernstein e tem como objetivo resolver todos os problemas de seus servidores antecessores, principalmente no quesito segurana, de forma a torn-lo rpido, eficinte e de fcil administrao, possuindo assim uma curva de aprendizado menos acentuada.

O principal objetivo do qmail era claro, substituir os servidores Sendmail e Postfix. Atualmente ele considerado o servidor de email mais rpido do mundo sendo o segundo servidor mais utilizado, perdendo apenas para seu antecessor, Sendmail, por motivos histricos.

Podemos citar algumas empresas famosas que utilizam o qmail como : Google, Usa.net, Yahoo!, Network Solutions, Critical Path, Verio, Message Labs, Hypermarket, PayPal/Confinity, entre outros.

Atualmente o qmail considerado o servidor de e-mail mais seguro do mundo contando inclusive com um prmio de USD$ 1.000,00 para o primeiro que encontrar alguma falha de segurana referente ao cdigo padro do qmail, falha esta no encontrada desde sua criao at a data presente deste trabalho

.

5.2. Segurana e Estrutura HierrquicaO sistema de e-mail qmail formado por basicamente 4 softwares: qmail-1.03, ucspi-tcp, daemontools e checkpassword, que possuem as seguintes funes: qmail-1.03 : O qmail-1.03 o daemon principal que prov suporte aos protocolos smtp e pop3. O suporte a outros protocolos, como imap e ssl, so providos por daemons externos ao sistema qmail mas que tem total integrao a ele. ucspi-tcp : O ucspi-tcp uma subimplementao de superdaemon feito especialmente por Dan J. Bernstein para o sistema qmail, de maneira a substituir os deficientes, porm padres histricos, softwares inetd e xinetd dos sistemas Linux, de forma a obter mais performance e flexibilidade. A sigla ucspi significa Unix Client-Server Program Interface. Ele constituido por vrias ferramentas e permite conexes TCP com o qmail e uma alternativa mais segura que o inetd/xinetd. Com o ucspi-tcp pode-se criar criar daemons de servidores-tcp e clientestcp.

daemontools : O daemontools funciona como um sistema de gesto bastante avanado para os processos do qmail e constituido por um conjunto de pequenas ferramentas, citadas adiante. O daemontools permite a implementao de uma relao de confiana entre os servios que dele dependem, uma vez que tem mecanismos para arranque automtico de daemons no caso de eles deixarem de funcionar sem razo aparente.. checkpassword : Este software permite a autenticao durante o processo do protocolo POP, isto , no acesso as mensagens armazenadas na caixa de correio do usurio. Ele consiste em uma interface simples e uniforme para autenticao de passwords dentro de qualquer aplicao root. Tambm pode ser til para a instalao de aplicaes futuras tais como o login, ftpd e pop3d.

Ao contrrio de seus antecessores o qmail possui vrios daemons executados com relao de confiana entre eles, cada um possui funes e usurios de controle diferentes. Existe apenas um daemon no sistema qmail que gerenciado pelo usurio root, que na verdade o daemon principal que faz o controle de todos os outros, mesmo assim nem o daemon principal nem o resto do sistema fazem uso do bit de permisso especial SUID, tornando assim o qmail mais seguro ainda ao nvel do sistema. Isto visa maximizar sua performance bem como facilitar o controle dos daemons, fazendo com que um falha em qualquer um deles mantenha um possvel problema isolado do resto dos servios.

O qmail possui basicamente 6 usurios destinados ao controle de cada um de seus daemons, nenhum destes usurios possui um shell real tornando assim o sistema mais seguro. Os usurios e grupos do qmail so os seguintes: alias : Este usurio responsvel por controlar todos os aliases do sistema. Existe de forma anloga ao servidor sendmail e possui a mesma estrutura dando assim total suporte ao sistema sendmail. qmaild : Este usurio utilizado para executar o servidor tcp especial do qmail chamado tcpserver. qmaill : Este usurio utilizado pelo daemon splogger, responsvel por logar toda e qualquer atividade ao daemon padro de logs do Linux, o syslogd. atravs do splogger que o qmail consegue enviar logs ao sistema Linux. qmailq : Este usurio utilizado para executar o daemon qmail-clean, responsvel por eliminar mensagens e usurios de email que estejam na memria do servidor com relay ainda aberto. qmailr : Este usurio utilizado para executar o daemon qmail-rspawn, responsvel por enviar mensagens para servidores remotos. qmails : Este usurio utilizado para executar o daemon qmail-send, utililzado para enviar e-mails provenientes da fila do qmail que gerenciada pelo daemon qmail-queue. root : Este usurio utilizado para executar os daemons qmail-queue qmail-lspawn, responsvel por enviar mensagens para o servidor local.

Seu funcionamento bem simples seguindo sempre uma linha lgica de funcionamento dos daemons regida pela seguinte figura:

Figura 2 Esquema de daemons do qmail (LIFE WITH QMAIL, 2007) O qmail diferencia mensagens recebidas localmente e remotamente por dois daemons diferentes, respectivamente qmail-smtpd e qmail-inject. O daemon qmailsmtpd aceita conexes de servidores de correio remotos e encaminha estas mensagens para o daemon qmail-queue, resposvel pela gerncia da fila de mensagens do sistema qmail. Da mesma forma temos o daemon qmail-inject que recebe conexes locais e envias suas mensagens para o daemon qmail-queue. O qmail-queue gerencia a fila de forma a entregar suas mensagens, atravs do daemon qmail-send, para os

MTA remoto. O qmail-send responsvel por enviar qualquer mensagem que exista na fila do qmail-queue. Para fazer isso ele chama um dos dois daemons, qmailrspawn ou qmail-lspawn, conforme o caso (remoto/local). O qmail-remote entrega as mensagens dirigidas aos servidores remotos enquanto o qmail-local entrega as mensagens destinadas a um usurio local.

5.3. Licena de UsoO qmail possui uma licena de uso especial. O qmail pode ser alterado de qualquer forma possvel a melhorar seu funcionamento porm seus pacotes no podem ser redistribuidos com estas alteraes se no foram explicitamente aprovados por seu desenvolvedor, Dan J. Bernstein. Isso quer dizer que pela sua licena, mesmo que seja feita alguma alterao em seu cdigo, ele deve ser distribuido intacto.

5.4. Problemas existntesO qmail no possui desenvolvimento de seu cdigo, por seu criador, desde o ano que foi criado em 1996, devido a isto ele no est em conformidade com os paradigmas atuais de servidores de e-mail no que tange novas funcionalidades e softwares existentes. Para tanto necessrio utilizar patches para correo e implementao dessas funcionalidades bem como utilizao de outros programas para tornar o qmail um ambiente de servidor de e-mail completo e atual.

O problema est na existncia de diversos patches e softwares diferentes para a implementao das mesmas funcionalidades, gerando assim uma redundncia. Estes softwares muitas vezes no so compatveis entre s causando problemas quando da compilao do cdigo do qmail. Para adequar o qmail aos novos paradigmas de segurana e funcionalidades estas melhorias em seu cdigo, via software, tornam-se madatrias, portanto impossvel conseguir um qmail realmente adequado a esses novos paradigmas quando utilizado com seu cdigo padro intalterado. Todas essas alteraes fazem com que no haja padronizao na implementao e configurao do sistema dificultando o trabalho do administrador, visto que cada adminsitrador s utiliza o necessrio para o seu cenrio atual, muitas vezes este cenrio no exige uma implementao completa e avaada do qmail.

obrigao do administrador do servidor conseguir um grupo de pacotes e patches estveis o bastante de modo a no comprometer a performance e segurana do servidor.

Outro problema que para se criar um servidor nesses novos paradigmas necessrio o uso de patches e novos softwares, para tal necessrio integr-los, operao esta apenas possvel quando compilamos novamente o qmail via cdigo fonte, o que gera um overhead no tempo de criao de um servidor.

6 OTIMIZAES DO SLACKWARE PARA QUBIT

6.1. Pacotes utilizados e descartadosA distribuio Slackware composta por 3 CDs de instalao dos quais apenas os dois primeiros so utilizados para uma instalao padro. No caso de uma instalao no perfil desktop interessante instalar o Slackware Linux com todos os pacotes, na qual os dois primeiros CDs so necessrios totalizando assim 1.2 Gb de espao em mdia que pode ser gravado em CD ou DVDs. Se esta instalao for feita adicionando-se os softwares contidos no ltimo CD ela totalizar um espao de 1.9 Gb entre softwares e bibliotecas.

O escopo deste trabalho desenvolver uma distribuio voltada a utilizao de servidores de e-mail portanto no se torna necessrio a instalao de pacotes fora do deste escopo. Foram excluidos da distribuio Slackware os pacotes dos seguintes escopos: Servios : Foram descartados todos os pacotes relativos a servidores

no utilizados como sendmail, servidores de impresso, fontes,

roteamento entre outros. Houve tambm a excluso de servios considerados superdaemon como inetd e xinetd instalados por padro nas distribuies Linux para levantar e derrubar por demanda servios configurados. Este superdaemon foi substituido pelo ucspi-tcp utilizado para o mesmo fim em relao aos daemons do sistema qmail. Os servios inetd e xinetd produzem um grande overhead para executar servios diminuindo tambm assim a performance do servidor no que tange a utilizao de CPU e Memria RAM para outros servios. Softwares e Bibliotecas: Foram excluidos todos os softwares e bibliotecas relativos a aplicaes no condizentes com o cenrio atual como bibliotecas grficas, svga, seejpeg, seebmp, aplicativos e bibliotecas de som, ferramentas para clculo matemtico, player de som e bibliotecas relativas. Redes : Foram tambm excluidos softwares para interconectividade de redes no pertinentes ao projeto como wireless, bluetooth, e suas bibliotecas. Ambiente Grfico : Todo e qualquer pacote relativo a servidores de ambiente grfico, Xfree86, Xorg, bem como ambientes grficos como KDE, GNOME entre outros foram excluidos. Todos os aplicativos que executam nestas plataformas tambm foram excluidos. Enfim foram excluidos todos os pacotes relativos aos grupos Y, X, XAP, TCL, T, KDE e KDEI. Esta operao resultou na reduo de praticamente 500Mb da instalao. Estes pacotes foram excluidos por no serem necessrios um servidor de e-mail e tambm por reduzirem a performance do mesmo.

6.2. Empacotamento de softwaresDevido a necessidade de otimizao de certos pacotes na rede, bem como a criao de outros, por motivos de performance e reduo no tempo de instalao dos mesmos, foram criados pacotes para todos os softwares utilizados no projeto. Para a adequao ao modelo de empacotamento do slackware e tambm para manter a compatibilidade foram utilizados softwares especficos do prprio sistema para o empacotamento como pkgtool, makepkg, installpkg, checkinstall, bem como ferramentas e bibliotecas de compilao padres da linguagem C como make, gcc e glibc.

No ato da compilao do software via cdigo fonte podem ser passados parmetros para que algumas de suas caractersticas sejam alteradas como diretrio de configuraes, diretrio de armazenamento dos binrios gerados, diretrio onde sero localizadas as bibliotecas utilizadas pelos binrios, entre outros. Para no comprometer a estrutura de cada um dos pacotes, levando assim um possvel problema de quebra de dependncia em suas bibliotecas compartilhadas, no foram alteradas caractersticas em relao a pacotes j existentes na distribuio, com apenas 3 excesses em relao aos pacotes apache, php e mysql. Todas as outras alteraes foram feitas em relao aos arquivos principais de configuraes instalados para cada pacote padro.

A criao de pacotes infere duas operaes diferente, uma para pacotes prexistentes onde apenas so alterados os arquivos de configurao e alguns diretrios, e para pacotes no existentes onde preciso compilar, e antes da instalao, criar os pacotes para instalao conforme softwares de empacotamento padro do sistema.

Na primeira opo, modificao de pacotes pr-existentes, primeiramente o contedo do pacote extraido usando-se ferramentas de compactao como tar, bzip e gzip. Depois de toda e qualquer alterao executada deve-se gerar novo pacote com os comandos citados no pargrafo anterior. O processo de criao para pacotes j existentes pode ser visualizado por completo no bloco texto abaixo: Alterao de pacotes compilados do cdigo fonte :

root@root root@root root@root root@root root@root root@root root@root

/root /root /root /root /root /root /root

# # # # # # #

tar xvzf pacote.tar.gz cd pacote/ ./configure make mkdir /tmp/temp_pacote/ make install DESTDIR=/tmp/temp_pacote/ cd /tmp/temp_pacote

Executar qualquer alterao necessria root@root /root # makepkg pacote.tgz

Alterao de pacotes pr existentes :

root@root /root # mkdir /tmp/temp_pacote/ root@root /root # installpkg root /tmp/pacote pacote.tgz root@root /root # cd /tmp/temp_pacote Executar qualquer alterao necessria root@root /root # makepkg pacote.tgz

6.3. Menus Interativos de InstalaoO Slackware Linux possui uma instalao bem intuitiva e leve em relao s instalaes dos demais linux existentes. Ela baseada inteiramente em script criados em shell (Shell Scripting) utilizado a biblioteca Ncurses responsvel por desenhar todas as telas de modo a otimizar e facilitar a instalao. O slackware faz uso tambm da ferramenta dialog, que atravs da biblioteca ncurses, serve de front-end para configurao de menus e mensagens na instalao.

Todo e qualquer menu de instalao criado na distribuio Qubit Linux manter este mesmo padro. No objetivo deste projeto criar menus interativos complexos ou visualmente mais agradveis. Nosso objetivo em relao estes menus implementar diversas funciolidades bsicas necessrias inexistentes no Slackware.

6.3.1. Particionamento Manual e AutomticoPor padro qualquer Linux para ser instalado deve ter primeiramente sua midia de instalao (Hard disk, Pen drive entre outros) particionada de forma a receber o sistema. Este particionamento pode ser executado de forma automtica ou manual no ato da instalao de diversos linux via menu interativo normalmente utilizando diskdruid , parted, entre outros como respectivamente nos Linux Redhat Enterprise e Slax. O Linux slackware no possui menu interativo para particionamento na instalao o que gera a necessidade de fechar o terminal de instalao e particionar o hard disk manualmente atravs da interface de console via shell.

Para o particionamento podem ser utilizados basicamente dois particionadores destrutivos : fdisk e cfdisk. A diferena entre eles se deve a maior intuitividade do cfdisk em relao ao fdisk. Devido a sua intuitividade e facilidade de uso o cfdisk foi o particionador escolhido para este projeto.

Outra funcionalidade bsica inexistente no Slackware a re-leitura da tabela de parties aps um particionamento bem sucedido, forando assim ao usurio que execute um boot no servidor para que ela seja relida e reconhecida pelo processo de isntalao do sistema linux em questo. Esta operao executada pelo comando PARTPROBE inexistente nas verses 10.2 e 11 do Slackware Linux. O software partprobe foi instalado como um meio de dinamizar a instalao evitando a perda de tempo no reboot do servidor e tambm a saida da interface de menus interativos para sua execuo. A adio deste software culmina com um ganho de tempo de aproximadamente 5 minutos de boot.

Foi desenvolvida uma interface responsvel pela configurao visual tanto automtica como manual da etapa de particionamento. Este menu foi feito em duas etapas, primeiramente verificamos a existncia e qual o tipo de hd existe no servidor bem como sua localidade na controladora IDE/SATA/SCSI em questo. Foi desenvolvido um script em Shell Script para este fim utilizando-se expresses regulares. assim gerada uma lista com diversos dispositivos encontrados pela inicializao da instalao com dados passados pela BIOS (Figura 3). Para gerao desta lista consultado o arquivo /proc/partitions em busca de parties encontradas pelo prprio sistema, atravs deste arquivo gerada uma lista de opes para a escolha do hard disk utilizado na instalao. Esta lista ento desenhada pela ferramenta dialog que utiliza as bibliotecas ncurses para criao de menus interativos

via shell. desenhado portanto o menu de escolha de particionamento que possui duas opes: Particionamento Automtico e Particionamento Manual (Figura 4). Para o menu de Particionamento Automtico ainda existem dois perfis utilizados onde apenas o primeiro o escopo deste projeto. Este particionamento automtico particiona o hard disk escolhido de forma padronizada escolhida pelo projeto.

Figura 3 Lista de Hard Drives encontrados pelo particionamento

Figura 4 Particionamento Manual ou Automtico

Verifiquem que o escopo de particionamento em nossa distribuio apenas de Hard Disks baseados em controladores IDE/SATA. No foram feitos testes extensivos para Hard Disks em controladoras SCSI embora o kernel utilizado oferea este suporte.

6.4. Kernel e PatchesO kernel, tambm chamado de ncleo, o cerne do sistema, ele responsvel por verificar e controlar dispositivos de hardware, controlar interrupes, acesso memria e ao discos, implementao e verificao de segurana, gerncia de sistemas de arquivos, deteco e correo de falhas nos hardwares, entre outras funes. Para tanto necessrio que o kernel utilizado tenha um bom suporte a hardware para se adequar aos mais variados ambientes de servidor encontrados no mercado.

O kernel utilizado para este projeto o vanilla verso 2.6.21.5. Chamamos de kernel vanilla os kernels padres encontrados no repositrio central de kernels para Linux (www.kernel.org) . A diferena que foram aplicados alguns patches ao kernel para dar suporte a alguns dispositivos e sistemas de arquivos listados abaixo.

6.4.1. Patch para ReiserFS v4.0H uma discuo intensa entre a comunidade e o mercado corporativo sobre qual sistema de arquivos utilizar. Este vai depender do escopo da soluo proposta. Existem diversos tipos de sistemas de arquivos famosos, podemos citar alguns como

FAT16, FAT32, NTFS para windows. Para os sistemas Linux os mais conhecidos so EXT2, EXT3, ReiserFS e XFS. Existem diversas diferenas entre cada um deles.

O sistema de arquivos EXT2 por natureza um dos mais rpidos por no possuir tantos recursos como seus sucessores, como suporte Journaling, o que infere uma probabilidade maior de perda de dados quando de um problema no disco. J o EXT3 possui as mesmas funcionalidades do EXT2 porm com suporte journaling. Historicamente falando os sistemas mais utilizados, por serem mais antigos e maduros, so os EXT2 e EXT3. Recentemente vem sendo muito empregado em servidores de aplicao crtica, outro sistema de arquivos mais robusto e seguro chamado ReiserFS. Este sistema de arquivos j foi desenvolvido com suporte padro Journaling e baseado na estrutura de arvores B, ganhando assim muita performance. Sua verso estvel, e mais utilizada, a 3.6 pois vem suportada pela maioria dos kernels em vrias distribuies Linux atuais. Recentemente foi desenvolvida uma nova verso muito superior a esta em vrios quesitos. Podemos consultar os dados de cada um dos sistemas de arquivos nas tabelas abaixo:

Limits EXT2 Maximum Filename Length Allowable Caracters in Directory Entries Maximum Pathname Length Maximum File Size Maximum Volume Size 255 bytes Any expect NUL No Limit Defined 2 Gb to 1 Tb 2 Tb to 32 Tb EXT3 255 bytes Any expect NUL No Limit Defined

File Systems ReiserFS 4.032 bytes / 255 Characterers Any expect NUL No Limit Defined 8 Tb 8 Tb to 32 Tb Reiser4 3.976 bytes Any expect and NUL No Limit Defined 8 Tb to 16 Tb Indefinido

16 Gb to 1 Tb 2 Tb to 32 Tb

Tabela 5 Limites de sistemas de arquivos

Metadata Stores File owner Posix file permissions Creation Timestamps Last Access / Read timestamps Last metadata change timestamps Last archieve timestamps Access Control Lists Security / MAC Labels Extended Attributes / Alterante Data streams / Forks Checksum / ECC EXT2 Yes Yes Yes Yes Yes No Yes Yes Yes No

File Systems EXT3 Yes Yes Yes Yes Yes No Yes Yes Yes No ReiserFS Yes Yes Yes Yes Yes No Yes Yes Yes No Reiser4 Yes Yes Yes Yes Yes No Yes Yes Yes No

Tabela 6 Metadata de sistemas de arquivos

Features Hard Links Soft Links Block Journaling Metadata-only Journaling Case-sensitive Case-preserving File Change Log Internal Snapshotting / Branching XIP Filesystem-level encryption EXT2 Yes Yes No Yes Yes Yes No No No No

File Systems EXT3 Yes Yes Yes Yes Yes Yes No No No No ReiserFS Yes Yes Yes Yes Yes Yes No No No No Reiser4 Yes Yes Yes No Yes Yes No No No No

Tabela 7 Funcionalidades de sistemas de arquivos Podemos ver claramente que todas as funcionalidades contempladas pelos sistemas mais antigos so tambm implementadas no sistema ReiserFS, porm o ReiserFS possui outras funcionalidades no encontradas em sistemas antigos. A maior parte dos sistemas vem com suporte a ReiserFS verso 3.6, embora a mais atual seja 4.0. A verso mais atual mais robusta, tem maior performance na leitura e gravao

de arquivos, bem como suporte a limites bem maiores. Para adicionar o suporte a verso 4 do sistema de arquivos ReiserFS ao kernel deve-se aplicar um patch.

6.4.2. Patch para BootSplashUm dos fatores responsveis pela no adoo do sistema operacional Linux Slackware seu caracter pouco intuitivo e, em geral, seco do sistema. A inicializao do Slackware executada em modo verboso sem nenhuma preocupao esttica com o usurio final. bom frisar que nem sempre necessria uma visualizao completa do processo de boot pois o mesmo no pode ser interrompido de repente para alguma tarefa administrativa no caso de alguma falha, sendo esta falha s resolvida com a possvel necessidade de outro boot. Portanto no caso de algum erro, os logs do sistema podem ser verificados.

Devido a existncia de logs no sistema no h a necessidade de exibir todo erro encontrado quando da execuo de softwares na inicializao, bastando uma mensagem de funcionamento ou falha. Foram padronizadas todas as mensagens de sucesso como [ OK ], e todas as mensagens de falha como [ FAIL ], respectivamente coloridas de verde e vermelho. Deste modo a vizualizao fica mais simplificada, intuitiva e limpa para o usurio final bastando apenas, em caso de falha, verificar os logs para uma saida mais completa.

Para mascarar as mensagens de inicializao do boot foi adicionado o patch bootsplash (http://www.bootsplash.org/Welcome_to_the_graphical_world_of_Linux) ao kernel que adiciona uma tela inicial com barra de progresso. Esta tela suprime a visualizao de todas as informaes de inicializao, deixando assim o processo de

boot menos poluido. Mesmo suprimindo suas mensagens o bootsplash ainda fornece suporte a modo verboso via tecla de funo F2.

7 HARDENING

7.1. Hardening de SistemaAtualmente boa parte da quebra de sigilo em sistemas de computao tem como orgem do ataque funcionrios da prpria empresa. Estes por estarem dentro da empresa possuem ferramentas e informaes privilegiadas que lhes concedem conhecimento para executar vrios tipos de ataque. Outro fator importante a relao aberta de confiana entre a empresa e o funcionrio, onde pela viso da empresa o funcionrio um indivduo acima de qualquer suspeita.

A situao acima traz consigo um problema, ela termina por deixar os administradores de servios e sistemas da empresa mais atentos para o que chega seus servidores de fora da empresa, e mais descuidados com o inimigo interno, o funcionrio, abrindo assim uma brecha de segurana condicional.

Independente de confiar ou no em seus funcionrios, o administrador deve executar e manter polticas pesadas de segurana que permitam apenas ao

administrador, e pessoas autorizadas, a utilizarem ou chegarem a determinado servidor ou servio. Quando acessamos remotamente ou localmente um servidor, ou seja, quando possuimos um shell neste servidor mesmo no possuindo privilgios de usurio administrador (usurio root) e consequentemente no executando escritas em quase nenhum arquivo do sistema, o usurio normal tambm tem privilgios de leitura em vrios aspectos do servidor permitindo assim uma quebra de sigilo parcial.

Alguns arquivos do sistema pedem ateno especial. Arquivos que armazenam informaes de usurio, grupo e suas senhas, respectivamente /etc/passwd,

/etc/shadow, /etc/group, /etc/gshadow, devem ser retiradas as permisses para o grupo other de modo que apenas o usurio e grupo do root tenha acesso ao arquivo e nenhum outro.

Foram executadas as mesmas alteraes nos arquivos de configurao nos servios de agendamento de tarefas peridico e aperidicos, respectivamente CRON e AT. Seu contedo recebeu a linha de configurao root permitindo apenas que o usurio root possa agendar tarefas no sistema, deste modo controlando tambm as tarefas que porventura sejam agendadas para outros usurios.

Em sistemas Linux todos os usurios, por padro, podem executar reinicializao da mquina com a combinao de teclas CRTL+ALT+DEL, isto implica na possvel indisponibilidade de um servidor caso haja um usurio mal intencionado. Para inibir este problema foi comentada no arquivo /etc/inittab a linha responsvel por esta funcionalidade que compreende a configurao ca::crtlaltdel:. O reinicializao do sistema deve ser executada apenas pelo usurio root mediante execuo dos comandos halt, reboot ou init 6.

Para permitirmos que determinado software execute com as permisses de outro usurio, usamos um bit especial chamado SUID. Muitos comandos no Linux possuem este bit ligado desnecessriamente ocasionando assim uma possvel falha de segurana. Portanto esta permisso foi retiradas dos seguintes arquivos :

/bin/ping, /bin/mount, /bin/ping6, /bin/umount, /usr/bin/at, /usr/bin/cu, /usr/bin/rcp, /usr/bin/rsh, /usr/bin/uux, /usr/bin/chfn, /usr/bin/chsh, /usr/bin/sudo, /usr/bin/uucp, /usr/bin/wall, /usr/bin/lppasswd, /usr/bin/crontab, /usr/bin/crontab, /usr/bin/chage, /usr/bin/write, /usr/bin/traceroute6, /usr/bin/traceroute,

/usr/bin/fdmount, /usr/bin/slocate, /usr/bin/expiry, /usr/bin/newgrp, /usr/bin/passwd, /usr/bin/gpasswd, /usr/bin/rlogin, /usr/bin/uuname, /usr/bin/uustat,

/usr/bin/lockfile, /usr/bin/slrnpull, /usr/bin/procmail, /usr/lib/utempter/utempter, /usr/sbin/uuxqt, /usr/sbin/uucico, /usr/libexec/pt_chown.

Outro fator que pode melhorar a performance do servidor a quantidade de terminais disponveis na instalao. Embora em modo single user seja utilizado apenas um, em modo multi user esto disponveis 6 terminais tty1 tty6, e mais um especial para a execuo do ambiente grfico. No h necessidade de existirem tantos terminais pois o superusurio trabalha apenas com 1 ou 2 ao mesmo tempo, e tambm pelo fato de que um terminal aberto, mesmo no utilizado, consome memria do servidor reduzindo sua performance.

Portanto foram eliminados os terminais tty3 tty7, restando apenas tty1 a tty2 para interao com o usurio. Estas alteraes foram executadas com o comando sed para a substituio de strings em um arquivo.

Outra medida de segurana tomada foi a alterao e exibio de banners para login local e remoto de usurios. O banner alterado exibido sempre no incio de cada conexo ou login, antes do preenchimento de nome de usurio e senha. A mensagem foi configurada no arquivo principal para este fim localizado em /etc/issue, com a seguinte mensagem:################################################################################### # WARNING #

################################################################################### # # This is a Private computer system and is the property of this Company. # It is for authorized use only. Users (authorized or unauthorized) have no # explicit or implicit expectation of privacy. # # Any or all uses of this system and all files on this system may be # intercepted, monitored, recorded, copied, audited, inspected, and disclosed to # authorized site, Department of Energy, and law enforcement personnel, # as well as authorized officials of other agencies, both domestic and foreign. # By using this system, the user consents to such interception, monitoring, # recording, copying, auditing, inspection, and disclosure at the discretion of # authorized site or Department of Energy personnel. # # Unauthorized or improper use of this system may result in administrative # this system you indicate your awareness of and consent to these terms and # conditions of use. LOG OFF IMMEDIATELY if you do not agree to the conditions # stated in this warning. # # # # # # # # # # # # # # # # # # #

###################################################################################

7.2. Hardening de ServiosAtualmente grande parte da quebra de sigilo e invases a sistemas domsticos e corporativos se deve muitas vezes inabilidade do administrador em proteg-la de forma correta e eficaz, outra parcela se deve a erros existentes nos softwares, mais

conhecidos como backholes, que de forma no prevista abrem uma porta de entrada para um intruso em potencial. A customizao de servios de login remoto e locais do servidor que possuam algum suporte a rede chamamos de Hardening de Servios.

7.2.1. SSH e Servios de Acesso RemotoPode-se afirmar que praticamente todo acesso remoto utilizado para manuteno ou desenvolvimento de um servidor atual feito via shell seguro, mais conhecido como ssh. Desta forma criamos uma camada a mais de proteo pois neste caso o meio criptografado impossibilitando assim a captura e leitura de pacotes por ataques man-in-the-middle. Porm o ssh, por ser o servio de login mais amplamente utilizado, tambm um dos mais expostos a falhas devido a falta de configurao necessria para proteg-lo de forma eficinte. Em nossa implementao foram adotadas todas as medidas sugeridas pela NSA (Agncia de Segurana Nacional Americada) relativas ao ssh.

O ssh, ou Secure Shell, aceita conexes de protocolo TCP no socket 22. Existem atualmente dois protocolos suportados, verso 1.0 e 2.0, entre outras de passagem, sendo a 2.0 mais atual. Por padro o ssh responde primeiramente por requisies de clientes 2.0, uma vez no encontrando clientes nesta verso o daemon altera automticamente a requisio para 1.0, dentro de uma sequncia lgica prconfigurada, afim de suportar vrios protocolos. A verso 1.0 considerada

insegura, tendo sofrido vrios problemas relacionados exploits e obteno de acesso remoto root via ataques de buffer overflow. Utilizamos portanto apenas a verso 2.0,

forando a utilizao de clientes com suporte a verso mais nova aumentando a segurana do servio. Esta opo configurada pela linha Protocol 2.

Para melhor esclarecer o usurio responsvel pela conexo remota sobre as polticas atuais de segurana do servidor, a primeira ao tomada a exibio do mesmo banner anterior, /etc/issue, no incio de qualquer conexo remota como um aviso.

Outro fator que contribui para o aumento da probabilidade de um ataque o fato de que o ssh por padro no limita acessos por usurio ou nmero de conexes, portanto permitindo acesso remoto ao usurio root quantas vezes forem requisitados. Mesmo que um atacante desconhea a senha, atravs de um ataque brute force ou wordlist ele est livre para tentar indefinidamente.

Para inibir este tipo de ataque ao daemon foi criado o usurio de sistema admin responsvel por todo e qualquer login remoto ou local, portanto apenas ele tem authorizao, configurada pela tag AllowUsers admin. Uma vez vetado o acesso remoto ao usurio root a configurao pertinente tambm foi excluida com a linha PermitRootLogin no. Para o limite de logins foi configurada a linha MaxAuthTries 5, setando em 5 o nmero mximo de autenticaes por minuto. Em caso de erro de senha 5 vezes seguindas o usurio automaticamente bloqueado, exigindo assim interveno local no servidor para a resoluo de problemas.

No permitida tambm a autenticao de usurios com senhas vazias, mesmo que elas existam. Esta funcionalidade configurada pela opo

PermitEmptyPasswords no.

Como a distribuio Qubit no possui ambiente

grfico no foram permitidas as configuraes para o servidor X11, setadas pelas opes AllowTcpForwarding no e X11Forwarding no.

Grande parte dos ataques ao ssh so derivados de Denial of Service, onde o servidor recebe uma enxurrada de pacotes inundando suas requisies terminado por no conseguir mais respond-las. Este ataque termina por derrubar o servidor ou deix-lo indisponvel por horas, as vezes dias. Alguns destes ataques podem ser feitos aps o login, tornando-os mais perigosos. Se o daemon ssh executa como standalone, ele automaticamente abre uma thread para cada login remoto ou local utilizado por usurio, deste modo aumentando a performance e diminuindo a probabilidade de danos. A configurao de cada um dos usurios remotos no root foi feita com o conceito de chroot jail (cadeia), pela configurao UsePrivilegeSeparation yes. Com isso asseguramos uma separao de privilgios onde o daemon dividido em duas partes onde uma pequena quantia do cdigo executa como root enquanto o resto executa em ambiente fechado via chroot jail, evitando que um ataque DDOS indisponibilize inteiramente o servidor, atingindo apenas para a thread origem ou destino do ataque.

Por medida de segurana foram vetados todos os mtodos de autenticaes baseadas em hosts como autenticao primria utilizando as configuraes: IgnoreRhosts yes, HostbasedAuthentication no, RhostsRSAAuthentication no. Estas autenticaes, embora funcionem por tnel criptografado, no possuem senha, por isso so baseadas em hosts. Por no possuirem senha mostram-se ineficazes aos paradigmas de segurana atuais. A configurao do daemon pode ser vista a seguir:# SSH Config # Hardened by Qubit Linux

Protocol 2 Port 22 PermitRootLogin no PermitEmptyPasswords no UsePrivilegeSeparation yes Banner /etc/issue ClientAliveinternal 1200 ClientAliveCountMax 0 IgnoreRhosts yes RhostsAuthentication no RhostsRSAauthentication no HostbasedAuthentication no AllowTcpForwarding no X11Forwarding no StrictModes yes SyslogFacility AUTH AllowUsers admin MaxStartups 10 MaxAuthTries 5 #EOF

8 QMAIL E PATCHES

8.1. Comparao entre verses e padres atuaisO desenvolvimento de uma soluo completa de servidor de emails varia principalmente devido ao escopo de utilizao do administrador que o desenvolve. No h a necessidade de implementao de um software desnecessrio no sistema. Com isso so gerados diversos padres de instalao do qmail, sendo os mais conhecidos atualmente: qmailrocks, life with qmail, nrg4u e John Simpson.

A medida que cresce a demanda por aplicaes no escopo de segurana, bem como adio de funcionalidades adequando os servidores de e-mail aos paradigmas atuais, surge tambm uma gama de programas, muitas vezes redudantes, para uma mesma funo no sistema. Isto acarreta problemas de pois temos diversos programas que resolvem os mesmos problemas implementados com diversas linguagens que so normalmente incompatveis entre s. O conjunto de programas utilizados por um administrador tambm varia de acordo com o escopo. O mesmo acontece em relao aos patches para adio de novas funcionalidades.

Cada um dos padres supracitados utiliza um grupo de softwares e patches diferentes, causando problemas de incompatibilidade, e prolongamento na curva de aprendizado do sistema qmail.

Para adequarmos o qmail aos novos paradigmas de funcionalidades e segurana corporativo devemos fornecer um grupo concreto de programas e patches soluo de e-mail de forma que execute com segurana e performance.

Existem basicamente duas verses do qmail, qmail-1.03 e netqmail-1.05. na verdade a verso netqmail nada mais do que a verso original 1.03 com 8 patches recomendados. Neste projeto foi utilizada a verso original junto com outro conjunto de patches que incluiem os 8 recomendados pelo desenvolvedor entre outros 50. Em todos os outros padres utilizado o netqmail.

Para este projeto foi adotado o patch de funcionalidades combinado, de Tino Reichardt. Este patch possui adequao do cdigo do qmail diversas RFCs mais atuais, que outros patches dos padres anteriores no fornecem, portanto deixando o email em conformidade com todos os novos paradigmas e RFCs de e-mail.

Todas as configuraes do qmail localizam-se no diretrio /var/qmail/control, onde cada uma delas podem tambm ter diversos outros diretrios, detalhados no captulo XX sobre padronizaes da distribuio. Abaixo so listados os patches e medidas de segurana implementados por eles:

8.2. Medidas Anti-SpamAlgumas medidas anti-spam podem ser tomadas sem a necessidade de utilizao de um software para anti-spam como clamav etc. Diversas novas funcionalidades podem ser inseridas por meio de patches.

So frequentes envios de e-mail para destinatrios vazios fazendo com que a mensagem no consiga ser entregue ocupando processamento da mquina. Com um patch especial podemos exibir a mensagem de erro 221 2.0.0: I can break rules, too. Goodbye e fechar a conexo estabelecida caso um cliente envie um comando DATA (abertura de corpo da mensagem) mas nenhum campo RCPT TO (destinatrio da mensagem) eliminando perda de performance.

Com

o

patch

P0f,

controlado

pelo

arquivo

de

configurao

/var/qmail/control/p0fsock podemos detectar de forma passiva o fingerprint fornecido para assim identificar o servidor remoto, possibilitando filtros por sistemas operacionais. Podemos executar este filtro por mquinas que conectam no servidor (SYN mode), conexes do servidor para mquinas cliente (SYN+ACK mode), mquinas que no podem ser conectadas (RST+ mode) e mquinas que desejamos observar a comunicao. Podemos ainda, devido ao fingerprint, detectar a presena de firewall, Nat, Load Balancer, distancia ao sistema remoto e seu uptime (Tempo em execuo), e redes como DSL, OC3 (Cisco) entre outras.

Quando um determinado email enviado para determinado destinatrio, a existncia deste s checada quando do recebimento do e-mail ao servidor destino, caso a conta de e-mail destinatria no exista no domnio a mensagem retorna informando que a caixa destino inexistente, isto gera um problema de performance

visto todos os e-mails, reais ou no, serem enviados desnecessriamente do servidor ocasionando gasto excessivo de trfego. Com o patch realcrptto toda e qualquer mensagem tem seu campo RCPT TO checado localmente e remotamente, caso o destinatrio no exista a mensagem automaticamente descartada.

Foi tambm implementado outro patch para a verificao de remetente e destinatrio no mesmo formato que o patch realrcptto, que pode ser controlado no arquivo de configurao /var/qmail/control/rcptcheck. Neste arquivo configuramos a lista de SENDERs e RECIPIENTS que devem ser verificados. Por motivos melhoria de perf