Centro Universitário UNIBENNETT
Curso de Ciência da Computação
Monografia
Trabalho de Conclusão de Curso
Rio de Janeiro
2007.2
2
FELIPE MARTINS RÔLLA
ORIENTADOR: WILLIAM AUGUSTO R. DE SOUZA
DESENVOLVIMENTO, OTIMIZAÇÃO E
IMPLEMENTAÇÃO DE SEGURANÇA EM
SISTEMAS OPERACIONAIS LINUX PARA
SERVIDORES DE E-MAIL CORPORATIVOS
BASEADOS EM QMAIL
Monografia apresentada ao Centro
Universitário Bennett
do
Instituto
Metodista Bennett, como parte dos
requisitos para obtenção do título de
Bacharel em Ciência da Computação.
Centro Universitário Metodista Bennett
3
Rio de Janeiro 12/2007
4
TERMO DE APROVAÇÃO
FELIPE MARTINS ROLLA
DESENVOLVIMENTO, OTIMIZAÇÃO E IMPLEMENTAÇÃO DE SEGURANÇA
EM SISTEMAS OPERACIONAIS LINUX PARA SERVIDORES DE E-MAIL
CORPORATIVO BASEADOS EM QMAIL.
ESTE TRABALHO FOI JULGADO ADEQUADO PARA A OBTENÇÃO
DO GRAU DE BACHAREL EM CIÊNCIA DA COMPUTAÇÃO E APROVADO
EM SUA FORMA FINAL PELA DISCIPLINA DE TRABALHO DE CONCLUSÃO
DE CURSO
BANCA EXAMINADORA:
__________________________________
PROFESSOR
WILLIAM AUGUSTO R. DE SOUZA, M. SC.
__________________________________
PROFESSORA
GRAZZIELA FIGUEREDO, M. SC.
__________________________________
PROFESSOR
PROF. SANDOVAL GONÇALVES, M. SC.
5
Agradecimentos
Gostaria de agradecer a todas as pessoas que contribuirão direta ou
indiretamente para este projeto e que continuarão contribuindo com idéias, força e
dedicação. Ao meu orientador William Augusto R. de Souza que acreditou em mim
quando ninguém acreditava. À Rafaela Haddad minha namorada pela dedicação e
compreensão por todo este tempo. Ao Coordenador e Prof. José Xexéo por sempre
buscar o melhor esforço 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 contribuíram para o projeto trazendo sugestões,
palavras de força nos piores momentos. À Tino Reichardt, contribuidor do projeto,
que nos cedeu a licença de utilização de seus softwares e à Dan. J. Bernstein,
desenvolvedor do qmail, sem eles este trabalho não seria possível.
Aos professores Fernando Miranda, Nelson, que sempre acreditaram neste
projeto deste o princípio.
6
7
SUMÁRIO
SUMÁRIO .........................................................................................................................6
Índice de Figuras ...............................................................................................................9
Índice de Tabelas .............................................................................................................10
Glossário ..........................................................................................................................11
1 - Introdução...................................................................................................................13
1.1. Motivação .............................................................................................................15
1.2. Objetivos ...............................................................................................................16
1.3. Etapas de desenvolvimento ..................................................................................17
2 – Licença de Software .................................................................................................19
2.1. Definição ..............................................................................................................19
2.2. Software livre .......................................................................................................20
2.2.1. GNU Public License (GPL) ...............................................................................21
2.3. Software proprietário ............................................................................................22
2.3.1. Creative Commons ............................................................................................23
2. 4. Comparação entre licenças ..................................................................................24
3 – Sistema Operacional Linux .......................................................................................26
3.1. História e definição ...............................................................................................26
3.2. Comparação entre Distribuições ...........................................................................28
3.3. Distribuição Slackware .........................................................................................32
4 – Servidores de e-mail código aberto ...........................................................................34
4.1. Definição e Funcionamento ..................................................................................34
8
4.2. Sendmail, Postfix e Qmail ....................................................................................38
5 – Qmail .........................................................................................................................41
5.1. Definição ..............................................................................................................41
5.2. Segurança e Estrutura Hierárquica .......................................................................42
5.3. Licença de Uso .....................................................................................................46
5.4. Problemas existêntes.............................................................................................46
6 - Otimizações do Slackware para Qubit .......................................................................48
6.1. Pacotes utilizados e descartados ...........................................................................48
6.2. Empacotamento de softwares ...............................................................................50
6.3. Menus interativos de instalação ............................................................................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 Serviços ..........................................................................................64
7.2.1. SSH e serviços de acesso remoto .....................................................................64
8 - qmail e Patches ...........................................................................................................68
8.1. Comparação entre versões e padrões atuais .........................................................68
8.2. Medidas Anti-Spam ..............................................................................................70
8.3. Medidas de Autenticação e Segurança .................................................................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 serviços ............................................................................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 - Padronização ............................................................................................................86
9
10.1. Diretórios e Links ...............................................................................................86
10.2. Arquivos e Conteúdo ..........................................................................................87
11 - Conclusão .................................................................................................................93
12 - Objetivos Futuros .....................................................................................................95
12 - Referências Bibliográficas .......................................................................................96
10
ÍNDICE DE FIGURAS
Figura 1 - Funcionamento do Correio Eletrônico (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 Automático ............................................................8
Figura 5 - Alguma coisa ..................................................................................................64
Figura 6 - Alguma coisa .................................. ...............................................................64
11
ÍNDICE DE TABELAS
Tabela 1 - Comparação entre licenças de software (WIKIPEDIA, 2007).........................8
Tabela 2 - Aprovação de licenças por Organizações (WIKIPEDIA, 2007) ...................15
Tabela 3 - Dispositivos e Softwares de Segurança (WIKIPEDIA, 2007) ......................15
Tabela 4 - Arquiteturas de Processadores Suportadas (WIKIPEDIA, 2007) .................15
Tabela 5 - Usuários do servidor qmail (LIFE WITH QMAIL, 2007) ............................15
12
GLOSSÁRIO
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 informação 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 função regular o
tráfego entre redes distintas e impedir a transmissão e/ou recepção de dados
nocivos ou nào 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 segurança tomadas no aumento da segurança de código ou
determinado ambiente de computação.
IMAP - Internet Message Access Protocol
KERNEL - Cerne, é o núcleo de um sistema operacional e representa a camada de
software mais próxima ao hardware, sendo responsável 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 - Códigos auxiliares incluidos no código fonte para implementação de
funcionalidades ou correção 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 - INTRODUÇÃO
A Internet tem revolucionado o mundo dos computadores e da comunicação
como nenhuma outra invenção jamais conseguiu, ligando usuários de todas as partes
da Terra no clique de um botão. Invenções importantes como o telégrafo, telefone, fax
e outras serviram de base para preparação do cenário atual de super integração e
comunicação existente.
Os primeiros registros de interações sociais que poderiam ser realizados através
de redes de computadores que se tem notícia foram uma série de memorandos escritos
por J.C.R. Licklider, do MIT (Massachussets Institute of Technology), em agosto de
1962. Esta série de memorandos previa a existência de vários 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, começando 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 começava assim a
convencer a todos da possibilidade teórica das comunicações usando pacotes ao invés
de circuitos o que representou um grande passo para a criação 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
instituições
militares
americanas
para
dinamizar
as
comunicações entre postos, portanto demorou pouco tempo para que surgisse a
primeira troca de mensagens via rede, troca esta que só foi possível depois do
desenvolvimento do primeiro Processador de Interface de Mensagens (IMP) pelo
DARPA, em 1968. Após um mês de implementação 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 comunicação digital, e por assim dizer os
serviços de troca de mensagens conhecidos hoje como e-mail.
Atualmente a troca de mensagem via servidores de e-mail são responsáveis por
50% do tráfego 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 rápida popularização, facilidade de uso e pragas virtuais decorrentes disto. Devido
a este fato é importante que os sistemas funcionem de forma a possuírem performance
e segurança para atender a demanda do serviço na Internet.
1.1. Motivação
Atualmente existem diversas soluções para e-mail corporativo desenvolvidas por
vários fabricantes internacionalmente conhecidos como Microsoft (Exchange Server),
IBM (Lotus Notes Workgroup), Critical Path, entre outras. Cada uma dessas soluções
possui um conjunto de funcionalidades análogas porém condizentes diretamente a
política de serviços da empresa. É importante frisar que todas as soluções supracitadas
recaem sobre a licença de software proprietário, portanto sua utilização deve ser de
acordo as restrições técnicas e de custo impostas por cada desenvolvedor.
Para aumentar a concorrência 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 soluções livres, cada uma avaliada e testada pela grande comunidade
de software livre. A maior parte possui implementações próprias em ambientes Linux
previamente desenvolvidos
e padronizados transformando portanto sistemas
complicados e complexos em sistemas intuitivos e de fácil instalação e adoção no
meio corporativo. Porém a quantidade de distribuições Linux voltadas para o campo
de servidores de e-mail é diretamente relacionada à funcionalidades, praticidade e
facilidade de configuração do MTA (Mail Transfer Agent) ou cliente de e-mail
escolhido, sendo dele Postfix, Sendmail, entre outros. Sendo assim cada distribuição
Linux, embora use o mesmo MTA como foco, é implementada e desenvolvida de
forma totalmente diferente e muitas vezes incompatível com outros sistemas,
terminando por existirem diversas soluções diferentes para um mesmo problema. Isto
gera um aumento no esforço de suporte ao ambiente criado bem como inconsistência
de procedimentos.
Embora existam soluções análogas não inexiste atualmente uma distribuição
Linux para servidores de e-mail voltada totalmente para o MTA qmail. Um dos fatos
que contribuem para isto é a extrema complexidade quando da implementação de um
servidor completo qmail e também na existência de vários tutoriais completamente
incompatíveis entre si, gerando inclusive dúvidas quanto a sua implementação, já que
cada administrador implementa apenas os recursos pertinentes a sua rede esquecendo
muitas vezes que o sistema deve ser escalar permitindo assim uma utilização mais
dinâmica e extensa. Outro fato é o código do qmail não ser intensamente mantido por
seu criador o matemático Dan. J. Bernstein, desvantagem esta totalmente suprida pela
grande comunidade de software livre. Porém esta comunidade gera outros problemas
como desenvolver ferramentas diferentes para resolução de um mesmo problema
gerando assim uma gama de aplicações análogas, aumentando o trabalho do
administrador para padronização e criação de uma solução de e-mail concisa e estável.
1.2. Objetivos
Este trabalho é uma extensão dos esforços da comunidade de código aberto em
atuação na Internet no desenvolvimento de um sistema de e-mail padronizado,
eficiente e seguro. A proposta é desenvolver uma sistema operacional Linux baseado
na Distribuição Slackware 12.0 com foco na criação, instalação, configuração e
implementação de uma solução completa de serviço de e-mail baseado em qmail,
MTA desenvolvido pelo matemático Dan J. Bernstein como alternativa rápida e
segura ao famoso MTA Sendmail desenvolvido por Eric Allman. Este sistema será
desenvolvido de forma a aproximar o usuário leigo ao mundo dos servidores de e-mail
de forma a transformar o processo de implementação em um processo mais intuitivo e
totalmente padronizado.
O desenvolvimento deste projeto baseia-se no fato de que não existe
atualmente uma distribuição totalmente voltada para este servidor específico, como
existem para outros servidores como postfix e sendmail. Serão implementados os mais
novos conceitos de configuração de servidores seguros utilizando otimização de
código via patches, configurações, boas práticas de configuração de serviços e
hardening de sistema.
Este projeto visa dinamizar e facilitar a implementação e configuração de um
servidor de e-mail qmail seguindo os padrões de utilização corporativa atual,
reduzindo o tempo médio de tais operações de 48 horas para 1,5 hora máximo,
implementando um sistema totalmente integrado com softwares recomendados
atualmente como antivírus, anti-spams, e políticas de segurança de sistema e serviços.
1.3. Etapas de desenvolvimento
Foram realizadas pesquisas sobre os principais MTAs de código aberto
utilizados atualmente em serviços de e-mail. As pesquisas levaram em conta
componentes estruturais, funcionais e de segurança na avaliação das diferenças entre
cada um dos MTAs utilizados como base na escolha do MTA abordado. São traçados
vários paralelos pertinentes a segurança, estabilidade, funcionalidade, freqüência de
atualizações oficiais e da comunidade de código aberto, instalação, configuração e
uso, assim como estudos de casos reais de utilização no meio corporativo.
Foram realizadas também pesquisas de intuitividade quanto a instalação do
sistema, e funcionalidades pertinentes a este fim bem como extensa pesquisa sobre
hardening (implementações de segurança) de sistema operacional Linux e serviços de
e-mail qmail na criação de um serviço seguro.
2 – LICENÇA DE SOFTWARE
2.1. Definição
Uma licença de software compreende permissões, direitos e restrições à A um
determinado software, sendo ele apenas um componente ou um programa completo. A
utilização de um software sem obedecer as restrições impostas por sua licença podem
constituir em uma infração dos direitos exclusivos do desenvolvedor do software
sobre copyright ou, ocasionalmente , lei de patentes permitindo ao dono do software
licenciado direitos para processar o usuário que a infringiu.
Sob a licença de software, ela permite a utilização do software desde que esta
esteja de acordo com os termos da licença. Se há uma brecha na licença, dependendo
do tipo, pode terminar por conceder direitos ao proprietário da licença do software à
processar quem a infringiu.
Um desenvolvedor de software pode oferecer uma licença unilateral (sem dar
ao licenciado oportunidades para renegociação de termos mais favoráveis), ou mesmo
como parte de um acordo de licença de software com terceiros. Virtualmente todo
software proprietário produzido em larga escala é vendido sob alguma forma de
licença. Os termos de tais licenças normalmente são negociados entre as partes,
licenciador e licenciado.
Em adição a garantia de direitos e imposição de restrições à utilização do
software, as licenças tipicamente contém procedimentos que denotam confiabilidade e
responsabilidade entre as partes. Em softwares corporativos e softwares de transação
comercial são normalmente negociados por equipes especialistas em licenças de
software.
2.2. Software Livre
São denominados softwares livres, ou de domínio público, os softwares cuja
licença permite qualquer tipo de uso, alteração, cópia, venda, e distribuição desejada
pelo usuário em relação a seu código-fonte. Para que o código fonte possa ser alterado
e aperfeiçoado é imperativo que ele esteja disponível para download sem qualquer
restrição e de forma completa. Se um programa é livre ele pode ser facilmente
implementado em um sistema operacional também livre.
É importante enfatizar que software livre não é sinônimo 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 não podem ser
alterados ou redistribuídos pois muitas vezes seu código-fonte é fechado ou recai
sobre determinada licença que impede está operação.
Atualmente existem diversos tipos de licenças de software livre com as mais
variadas permissões e restrições. A licença escolhida para este projeto é a GPL, ou
GNU Public License, pela liberdade que apresenta em relação a cópia, alteração e
redistribuição de código nela registrado como explicado adiante.
2.2.1. GNU Public License (GPL)
A GNU Public License, ou simplesmente GPL, é a licença de software livre
criada e idealizada por Richard Stallman, fundador da Free Software Foundation
(FSF), no final da década de 1980. A GPL é a licença mais utilizada por projetos de
software livre no mundo. Ela baseia-se em 4 premissas básicas:

Liberdade de executar um programa para qualquer propósito (Liberdade
nº 0).

Liberdade de estudar como o programa funciona e adaptá-lo para suas
necessidades (liberdade nº 1). O acesso ao código-fonte é um prérequisito para estar liberdade.

Liberdade de distribuir cópias de modo que o usuário possa ajudar o seu
próximo (liberdade nº2).

Liberdade de aperfeiçoar o programa, a liberar os seus aperfeiçoamentos,
de modo que toda a comunidade se beneficie deles (liberdade nº 3). O
acesso ao código-fonte é um pré-requisito para estar liberdade.
Pelos termos da licença GNU podemos escrever, alterar, reenviar, trocar e
vender quaisquer alterações feitas no código-fonte pois ele é de utilização livre.
A licença GPL também possui outras duas sub-licenças: GNU FDL (GNU Free
Document License) e a GNU LGPL (GNU Light Public License), que compreendem
em licenças para documentação livre, e uma versão mais resumida e simples da GPL
padrão para o desenvolvimento de drivers, bibliotecas e pequenos módulos ou addons,
respectivamente.
Atualmente todo e qualquer software desenvolvido ligado a comunidade de
software e ao Free Software Foundation são licenciados sob a GPL.
2.3. Software Proprietário
Softwares proprietários são aqueles cuja cópia, redistribuição ou modificação
estão limitadas ou impossibilitadas pelas restrições de sua licença. Para utilizar,
copiar, alterar código ou redistribuir, deve-se solicitar permissão ao desenvolvedor ou
empresa que detém os direitos de propriedade do software requerido, ou pagar para
fazê-lo.
Algumas licenças de software proprietário possuem código livre que pode ser
utilizado e alterado apenas para uso próprio mas impõe restrições quanto a
redistribuição deste código modificado. Outras licenças permitem a utilização de
determinado software de modo ilimitado ou temporário sem oferecer o código-fonte
utilizado para compilá-lo. Existem ainda softwares cujos códigos-fontes não são
distribuídos, são apenas executados via software de instalação e ao mesmo tempo são
pagos, como é o caso de muitos sistemas operacionais utilizados no mercado
corporativo ou programas de cunho comercial. As restrições e permissões de cada
licença variam para cada empresa e proprietário de software.
2.3.1. Creative Commons
A licença Creative Commons permite aos proprietários de software garantir em
parte ou totalmente seus direitos de software ao público enquanto retém outros,
através de uma variedade de licenças e esquemas de contrato incluindo softwares de
domínio público ou termos de licença de conteúdo aberto. O objetivo deste tipo de
licença proprietária é evitar problemas com a lei de copyright no que tange o
compartilhamento da informação.
O projeto Creative Commons provê vários tipos de licença gratuitas as quais os
proprietários dos direitos de software possam utilizar no lançamento de seus trabalhos
na rede. Ao mesmo tempo que protege a propriedade intelectual de seus proprietários,
evita problemas com a lei e permite, dentro das restrições impostas pelo proprietário,
sua redistribuição, alteração e uso ao público.
Exemplos de projetos que utilizam esta licença são Wikimedia (Wikimedia,
2007) , Public Library of Science, Jurispedia, entre outros.
2.4. Comparação entre licenças
A tabela seguinte compara várias características de cada uma das licenças ,
como um guia para os termos que cada uma das licenças contém:
Autor
Última
Versão
Data de
Publicação
?
?
?
Link de
código com
licença
diferente
?
Apache License
Apache Software
Foundation
2
2004
Sim
Apple Public Source License
Licença
Academic Free License
Mudanças
sob licenças
diferentes
?
Sim
Apple Computer
2
6-Aug-03
Sim
Não
Artistic License
?
2
?
Sim
Com restrições
Berkeley Database License
?
?
?
?
?
BSD license
?
?
?
Sim
Sim
Boost license
?
?
?
Sim
Sim
Sun Microsystems
1
?
Sim
?
Common Public License
?
?
?
?
Não
Cryptix General License
?
?
?
?
?
Eclipse Foundation
1
?
?
?
Common Development and Distribution
License
Eclipse Public License
Educational Community License
?
1
?
Sim
Sim
GNU General Public License
Free Software Foundation
3
Jun-07
Não
Não
GNU Lesser General Public License
Free Software Foundation
3
Jun-07
Sim
Não
Hacktivismo/Cult of the
Dead Cow
?
26-Nov-02
?
?
IBM
?
?
?
?
Intel Corporation
?
?
?
?
LaTeX project
1.3c
?
?
?
?
?
?
Sim
Sim
Hacktivismo Enhanced-Source Software
License Agreement
IBM Public License
Intel Open Source License
LaTeX Project Public License
MIT license
Mozilla Public License
Mozilla Foundation
1.1
?
Sim
Não
Netscape Public License
Netscape
1.1
?
?
?
Open Software License
?
?
?
?
?
OpenSSL license
OpenSSL Project
?
?
?
?
PHP License
PHP Group
Python Software
Foundation
Trolltech
3.01
?
?
?
2
?
?
?
?
?
Não
Não
Sun Industry Standards Source License
Sun Microsystems
?
?
?
?
Sun Public License
Python Software Foundation License
Q Public License
Sun Microsystems
?
?
Sim
Não
W3C Software Notice and License
?
?
?
Sim
Sim
X11 license
?
?
?
Sim
Sim
XFree86 1.1 License
?
?
?
?
?
zlib/libpng license
?
?
?
?
?
Zope Public License
?
?
?
?
?
Tabela 1 – Comparação entre licenças de software (WIKIPEDIA, 2007)
A tabela abaixo lista para cada licença quais organizações as aprovaram como
open source (código livre) e como está organizações as categorizam. Estas
organizações aprovam normalmente versões específicas de licenças.
FSF
approval
OSI
approval
Academic Free License
Sim
Sim
Apache License
Sim
Sim
Apple Public Source License version 1.x
Não
Sim
Apple Public Source License version 2.0
Yes
Sim
Artistic License
Não
Sim
Clarified Artistic License
Sim
Sim
Berkeley Database License
Sim
Sim
BSD license
Sim
Sim
Common Development and Distribution License
Sim
Sim
Common Public License
Sim
Sim
Cryptix General License
Sim
No
Eclipse Public License
Sim
Sim
Licence and specific version
Educational Community License
?
Sim
GNU General Public License
Sim
Sim
GNU Lesser General Public License
Sim
Sim
Hacktivismo Enhanced-Source Software License Agreement
No
No
IBM Public License
Sim
Sim
Intel Open Source License
Sim
Sim
LaTeX Project Public License
Sim
No
License of Python
Sim
Sim
MIT license
Sim
Sim
Mozilla Public License
Sim
Sim
Netscape Public License
Sim
No
Open Software License
Sim
Sim
OpenSSL license
Sim
No
PHP License
Sim
Sim
Q Public License
Sim
Sim
Sun Industry Standards Source License
Sim
Sim
Sun Public License
Sim
Sim
?
Sim
Sim
Sim
Sybase Open Watcom Public License
W3C Software Notice and License
XFree86 1.1 License
No
No
zlib/libpng license
Sim
Sim
Zope Public License version 1.0
Sim
?
Zope Public License version 2.0
Sim
Sim
Tabela 2 – Aprovação de licenças por Organizações (WIKIPEDIA, 2007)
3 – SISTEMA OPERACIONAL LINUX
3.1. História e Definição
Em 1991 praticamente todas as universidades do mundo utilizavam algum tipo
de Unix como sistema operacional acadêmico 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 licença era muito cara para o meio
acadêmico, as universidades passaram a adotar uma versão mais simples e com menos
recursos chamada Minix, um clone de código aberto do Unix desenvolvido
especialmente para suprir sua falta de verba. Como todo clone o Minix carecia de
recursos básicos, utilizado portanto vastamente apenas como sistema base para
projetos e trabalhos acadêmicos.
Um aluno da Universidade de Helsink na Finlândia, Linus Torvalds, não
concordava com esta visão e queria oferecer mais funcionalidades ao Minix fazendo-o
tão completo quanto seu similar corporativo. Ele iniciou seu projeto em meados dos
anos 1990 através 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 distribuído sem custos e de código livre.
Por definição o sistema operacional Linux nada mais é do que um clone código
aberto dos sistemas Unix da época possuindo kernel próprio desenvolvido por Linus
Torvalds em adição aos programas já existentes da FSF (Free Software Foudation)
fundada por Richard Stallman.
Devido a sua rápida adoção pelo mercado corporativo e doméstico, existem
atualmente diversas distribuições diferentes em funcionalidades e foco no mercado.
Exemplos disso são as seguintes distribuições:

Slackware
(www.slackware.org)
:
Desenvolvida
por
Patrick
Volkerding em Julho de 1993. É considerada a mais antiga e primeira
distribuição Linux completa.

Debian
(www.debian.org)
:
Distribuição mais
utilizada
por
desenvolvedores e acadêmicos de Linux pois segue completamente a
filosofia da GNU da Free Software Foundation, totalmente licenciada
pela GPL, ou seja, gratuito e de código aberto.

Redhat (www.redhat.com) : Distribuição Linux criada para o mercado
corporativo. Muitos de seus softwares são gratuitos porém praticamente
tudo que diz respeito ao mercado corporativo é restrito e de código
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 distribuição Linux
brasileira. Hoje não existe mais e foi integrada à distribuição Mandrake
formando assim uma nova distribuição chamada Mandriva.

Mandriva ( www.mandriva.com ) : Anteriormente conhecido como
Linux Mandrake, foi formada pela união da Mandrake com a Conectiva.
É atualmente uma das distribuições 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 distribuição
mais utilizada no mercado europeu.
3.2. Comparação entre Distribuições
Existem atualmente, entre distribuições corporativas e suas dissidências, cerca
de 90 distribuições famosas largamente utilizadas no mundo. Obviamente existem
outras dezenas dissidentes destas e portanto um pouco menos conhecidas. A escolha
de determinada distribuição, muitas vezes chamada de “flavor”, ou sabor, depende da
aptidão e gosto do usuário com o sistema em questão. Normalmente usuários mais
experientes preferem distribuições mais robustas e experientes com um maior número
de casos de sucesso como Slackware, Debian e Redhat, distribuições estas com maior
respaldo da comunidade de software livre, ou de seus fabricantes. Usuários de entrada
ou inexperientes preferem distribuições de escopo técnico menor e mais intuitivas
como CentOS, Suse e Mandriva, por serem mais fáceis de utilizar.
Esta escolha esta diretamente ligada as seguintes características:

Praticidade : É importante quando da utilização, manutenção e suporte
da distribuição. Operações que podem levar horas quando a compilação
de código é eminente podem ser reduzidas para minutos no caso da
existência de ferramentas dinâmicas e de fácil uso diminuindo assim o
tempo necessário com suporte e também a curva de aprendizado no
treinamento de um profissional da área.

Intuitividade : É importante para acelerar tarefas como manutenção do
sistema e principalmente mais importante para o usuário final. Sendo este
um usuário não muito técnico ter um sistema intuitivo, com softwares
facilmente localizados no ambiente de janelas ou linha de comando, é
primordial para um bom aproveitamento empresarial ou doméstico sem a
necessidade de auxílio profissional do suporte.

Segurança : Este é o item mais importante na escolha de uma
distribuição para servidores. É extremamente importante uma vez que o
Linux é considerado o sistema operacional mais adotado no meio
corporativo para serviços críticos como High Availability, Firewall,
VPN, E-mail entre outros. Deve-se verificar a freqüência de correções de
erros bem como atualizações 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 adoção
no mercado.
Como vimos a utilização é baseada no gosto e necessidade de cada
administrador, bem como o hardware disponível para utilização.
Outro paralelo de comparação necessário é em relação aos dispositivos de
segurança existentes em cada distribuição. Cada distribuição 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 distribuição mais largamente utilizada no meio corporativo o
qual quase sempre faz parte de um cenário totalmente heterogêneo, mas em relação a
segurança não é necessário grade suporte, apenas os básicos 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 são praticamente todos orientados à algum campo de
segurança e são as distribuições mais utilizadas para este fim, necessitando assim de
mais recursos neste quesito. Podemos portanto caracterizar as distribuições quanto a
este quesito na tabela a seguir:
Distribuição
AppArmor
BGCC
CentOS Linux
Não
Não
Debian Linux
Não
Não
Fedora Linux
Não
Não
Gentoo Linux
Red Hat Enterprise
Linux
Não
Exec
Shield
GrSecurity
PaX
Rsback
SELinux
Systrace
RSBAC
Sim
Não
Não
Opcional
Opcional
Não
Não
Sim
Não
Não
Não
Opcional
Não
Sim
Não
Não
Não
Não
Sim
Não
Não
Sim
Sim
Opcional
Sim
Não
Opcional
Opcional
Opcional
Não
Não
Sim
Não
Não
Não
Sim
Não
Não
Mandriva Linux
Não
SUSE Linux
Sim
Não
Sim
Não
Não
Não
Sim
Não
Não
Não
Não
Não
Não
Não
Não
Não
Slackware Linux
Sim
Não
Não
Opcional
Não
Não
Não
Sim
Opcional
Não
Tabela 3 – Dispositivos e Softwares de Segurança (WIKIPEDIA, 2007)
Na tabela supracitada não foram descritos os dispositivos de segurança da
distribuição 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 distribuição que é a quantidade de sistemas de arquivos
suportados pelo sistema. Geralmente distribuições de escopo corporativo possuem
uma maior desenvoltura neste aspecto visto atenderem os mais heterogêneos
ambientes em diversos tipos de empresa. Já distribuições não 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
não suportados por padrão em algumas delas podem ser incluídos por meio de código
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.
Distribuição
x86
x8664
IA64
ppc
ppc64
sparc32
sparc64
s390
s390x
alpha
CentOS Linux
Sim
Sim
Sim
Não
Não
Não
Não
Sim
Sim
Sim
Debian Linux
Sim
Sim
Sim
Sim
Não
Sim
Sim
Sim
Sim
Sim
Fedora Linux
Sim
Sim
Não
Sim
Não
Não
Não
Não
Não
Não
Gentoo Linux
Sim
Sim
Sim
Sim
Sim
Não
Sim
Sim
Sim
Sim
Red Hat Enterprise Linux
Sim
Sim
Sim
Sim
Não
Não
Não
Sim
Sim
Não
Mandriva Linux
Sim
Sim
Não
Sim
Não
Não
Não
Não
Não
Não
SUSE Linux
Sim
Sim
Sim
Sim
Não
Não
Não
Sim
Sim
Não
Slackware Linux
Sim
Não
Não
Não
Não
Não
Não
Sim
Não
Não
Tabela 3 – Arquiteturas de Processadores Suportadas (WIKIPEDIA, 2007)
3.3. Distribuição Slackware
O Linux Slackware é um sistema Linux avançado desenvolvido em 1993 pelo
programador Patrick Volkerding com o intuito de ter usabilidade e estabilidade como
prioridade. Ele inclui as mais novas versões dos mais novos softwares GNU
existentes, mantendo o tradicional senso de segurança e estabilidade do sistema,
provendo facilidade de uso e flexibilidade.
Desde sua primeira versão em 1993, sua proposta é de produzir um sistema mais
parecido com o Unix no que tange simplicidade, segurança e desempenho, ele foi
desenvolvido primeiramente seguindo os padrões dos Unixes BSD utilizados em
Berkeley como OpenBSD, FreeBSD, e NetBSD. O Slackware mantém suporte em
relação aos aspectos mais atuais de sistemas linux como FHS (File Hierarchy
Standard) com diretórios padronizados e estruturados, bem como ao padrão 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 versão 2.4,
desenvolvido por Linus Torvalds, com suporte também a versões 2.6 atuais. Todas as
versões de kernel baseadas na biblioteca GNU C versão 2.3.4 (libc6). Sua instalação é
intuitiva e simples contando com telas de ajuda ao logo do processo. Ele possui
extensa documentação no site oficial (www.slackware.org) e também em milhares de
fóruns de discussão associados. O sistema Slackware pode rodar em arquiteturas 486
em máquinas x86 como P3, P4, Athlon, Duron, entre outras.
O Slackware é a distribuição escolhida por este projeto pois como apóia seu
funcionamento em flexibilidade, simplicidade e estabilidade, nos fornece condições
favoráveis para desenvolvê-lo aplicando sua gama de funcionalidades para um
ambiente corporativo de servidores, suportando o escopo atual de um servidor de email estável, flexível e seguro. Outro fator que influenciou em nossa escolha foi o fato
do Slackware Linux ser a distribuição mais imples e flexível disponível permitindonos a alterá-la basicamente reconfigurando scripts simples de inicialização e
instalação, bem como criar nossos próprios. Ela nos permite uma escolha bem mais
simples de pacotes utilizados e descartados pelo sistema simplesmente apagando-os.
4 – SERVIDORES DE E-MAIL CÓDIGO ABERTO
4.1. Definição e Funcionamento
O servidor de e-mail, mais conhecido como mail exchanger (MX), no contexto
de um servidor de nomes de domínio é um software de computador instalado em um
determinado host capaz de transferir mensagens eletrônicas 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 são
softwares que se conectam em determinado servidor de e-mail de modo a enviarem
suas mensagens, e também são responsáveis por receber todas as mensagens
armazenadas em suas caixas postais eletrônicas neste servidor conectando-se ao
mesmo servidor, ou servidor diferente, para resgatá-las.
Como em toda conexão baseada em protocolos da pilha TCP/IP, a conexão do
MTA com o MX tem seu controle baseado no par IP:Socket, independente do serviço
utilizado pelo servidor, que pode variar de porta. Existem atualmente vários
protocolos que participam do funcionamento de um servidor de e-mail atual. São eles:

SMTP ( Simple Mail Transfer Protocol ) : Serviço 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 conexões TCP de
clientes MUA na porta 25.

POP ( Post Office Protocol ) : Serviço 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 conexões TCP na porta 110 no servidor.
Atualmente está na versão 3.

IMAP ( Internet Message Access Protocol ) : Serviço 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 evolução do protocolo POP já conhecido, pois fornece várias outras
funcionalidades não existentes neste. Seu servidor aguarda conexões
TCP de clientes MUA na porta 143.
Podemos definir o funcionamento de troca de mensagens padrão com a figura a
seguir:
Figura 1 – Funcionamento do Correio Eletrônico (WIKIPEDIA, 2007)
O usuário remetente da mensagem utiliza um MUA de sua escolha, como
Outlook, Thunderbird, entre outros, para conectar-se ao MTA que possui sua própria
caixa postal eletrônica, caracterizado na figura pelo Servidor A, via protocolo SMTP
na porta 25. Este MTA por sua vez verifica se a caixa do usuário remente existe. Caso
a conta inexista o MTA cancela a operação enviando ao MUA do usuário uma
mensagem de erro. Caso a conta exista o MTA faz consultas ao seu DNS para
encontrar que MTA no mundo contém a caixa de e-mail do destinatário. Uma vez
encontrado o destinatário o Servidor A acessa o MTA remoto, caracterizado na figura
pelo Servidor B, também com uma conexão TCP na porta 25 do Servidor B. Quando
o MTA Servidor B recebe esta conexão ele verifica se a conta do usuário remetente
existe, caso positivo a mensagem é entregue, caso negativo o Servidor A recebe a
resposta de que a conta destinatária não 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 usuário existe, negativo
o MUA emissor recebe uma mensagem de que a conta inexiste. Caso positivo o MTA
destino valida usuário e senha configurados no MUA e compara com as configurações
de sua conta. Caso usuário e conta existam e sejam válidos 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 diferença, em um servidor IMAP normalmente as imagens permanecem no
servidor por padrão. As únicas informações resgatadas pelo cliente são os índices da
caixa postal, ou seja, os nomes de assuntos das mensagens existentes e nada mais.
Caso o usuário 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 não possui apenas os serviços
básicos para troca de mensagens. A medida que a demanda por funcionalidades
aumenta, a necessidade por outros tipos de serviços se justifica. Serviços como
webmails que permitem aos clientes acesso a suas mensagens de qualquer lugar do
mundo simplesmente através da utilização de qualquer computador conectado a
internet via navegador web como Internet Explorer, Mozila Firefox, entre outros. Os
serviços de webmail por si só possuem funcionamento bem simples porém necessitam
de uma certa infra-estrutura para que funcionem tais como servidores de páginas,
suporte a linguagens web interpretadas e , dependendo da complexidade do software,
bancos de dados para armazenamento de mensagens e logs dos serviços.
4.2. Sendmail, Postfix e qmail
Em 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 porém sua
utilização decaiu muito pelo advento da criação de vários outros servidores de e-mail
mais modernos. O Sendmail possuia diversos problemas estruturais, primeiramente
ele foi feito para um ambiente de interconexão de redes quando a premissa básica era
a possibilidade de troca de mensagens e não a segurança do meio em sí visto que este
meio era muito caro impossibilitando sua utilização pela maior parte da população.
Com este fato apareceram diversos problemas de segurança provenientes de erros no
código e também da total falta de adequação ao paradigma da segurança.
Seus principais erros eram em relação ao código, muito em parte pela falta de
projeto e padronização no desenvolvimento de qualquer software existentes na época
o que também trazia outro problema, o tempo de manutenção do software que era
constantemente ultrapassado. A medida que os erros no daemon Sendmail iam
aparecendo era necessário um suporte eficaz para sua correção, quase sempre
acompanhada de patches e consecutiva recompilação do código onde era necessário
apenas um erro de uma linha de comando para que está compilação não fosse
executada com sucesso.
Suas caixas postais de usuários funcionavam no sistema Maildir padrão onde
cada mensagem ficava no diretório pessoal do usuário, e cada um dos usuários deveria
existir no servidor, fazendo com que se houvesse a necessidade de um servidor para
5.000 contas, deveriam existir 5.000 usuários, um para cada conta, configurado
corretamente no sistema de e-mail. Não havia ainda gerenciadores de domínios e
contas virtuais obrigando assim que cada usuário de e-mail também fosse um usuário
do sistema.
Outro erro crucial do sendmail era que seu daemon principal, como é chamado o
processo principal de um software servidor, era executado pelo usuário root,
administrador do sistema Linux, portanto qualquer falha explorada por um invasor em
potencial era explorada sobre este usuário, sendo ele o usuário administrador caso o
atacante conseguisse invadir o servidor por meio de alguma falha de buffer overflow
no servidor ele entraria com privilégios de root. Além do usuário root alguns
programas também eram utilizados com permissões SUID o que permitia que usuários
normais do sistema executassem programas com privilégios de root. Esta falha não era
apenas de segurança, era também estrutural uma vez que bastava apenas um erro no
daemon principal para que o sistema inteiro ficasse inoperante. A configuração do
servidor também era baseada apenas em um arquivo, extremamente complexo e não
intuitivo, onde eram feitas todas as operações de configuração básicas bem como
whitelists, blacklists e outras proteções ao servidor. Se este arquivo fosse
comprometido por erros no sistema de arquivo o serviço inteiro era comprometido. É
importante frisar que nesta época os sistemas de arquivos Journaling (sistemas de
arquivo com gravação e leitura serializada, evitando assim fragmentação)
ainda
estavam em fase de projeto. Todo sistema de arquivos não journaling é mais propício
a falhas, sendo estas mais difíceis de corrigir levando muitas vezes a um problema do
servidor mesmo ele não sendo gerado pelo serviço de email em sí.
O Sendmail foi feito em uma época onde a segurança não era tão essencial, e
este era exatamente seu ponto fraco. O sendmail não conseguiu acompanhar as rápidas
e frequentes mudanças nos paradigmas de segurança e novos serviços necessários 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 rápido, fácil de administrar e seguro. Ele possuia suporte completo ao
Sendmail pois suas bases eram as mesmas. Houve um grande avanço na instalação e
configuração que ficaram bem mais intuitivas e simples. Assim como o Sendmail ele
também era gratuito, lançado sob a licença GPL. Porém ele também possuia diversos
problemas. O principal é que mantinha a mesma base do sendmail o que o tornava um
pouco antigo para algumas configurações. Outro problema eram as constantes
atualizações de segurança pois sofria diversas invasões decorrentes de erros gerados
por código mal feito. Estas constantes atualizações também necessitavam de
recompilação de seu código fonte o que forçava a indisponibilidade do serviço para
que sua manutenção fosse executada. Embora suas atualizações de segurança fossem
lançadas constantemente o Postfix possuia o mesmo problema principal de executar
seu único daemon padrão com privilégios de usuário 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, rápido e de fácil administração, conforme discutido
no capítulo seguinte.
5 – QMAIL
5.1. Definição
O servidor qmail, projetado e desenvolvido em 1996 pelo pesquisador e
matemático Dan J. Bernstein e tem como objetivo resolver todos os problemas de seus
servidores antecessores, principalmente no quesito segurança, de forma a torná-lo
rápido, eficiênte e de fácil administração, 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 rápido do mundo
sendo o segundo servidor mais utilizado, perdendo apenas para seu antecessor,
Sendmail, por motivos históricos.
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 prêmio de USD$ 1.000,00 para o primeiro que encontrar
alguma falha de segurança referente ao código padrão do qmail, falha esta não
encontrada desde sua criação até a data presente deste trabalho
.
5.2. Segurança e Estrutura Hierárquica
O sistema de e-mail qmail é formado por basicamente 4 softwares: qmail-1.03,
ucspi-tcp, daemontools e checkpassword, que possuem as seguintes funções:

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,
são providos por daemons externos ao sistema qmail mas que tem total
integração a ele.

ucspi-tcp : O ucspi-tcp é uma subimplementação de superdaemon feito
especialmente por Dan J. Bernstein para o sistema qmail, de maneira a
substituir os deficientes, porém padrões históricos, 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 várias ferramentas e permite conexões
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 gestão
bastante avançado para os processos do qmail e é constituido por um
conjunto de pequenas ferramentas, citadas adiante. O daemontools
permite a implementaçào de uma relação de confiança entre os serviços
que dele dependem, uma vez que tem mecanismos para arranque
automático de daemons no caso de eles deixarem de funcionar sem razão
aparente..

checkpassword : Este software permite a autenticação durante o
processo do protocolo POP, isto é, no acesso as mensagens armazenadas
na caixa de correio do usuário. Ele consiste em uma interface simples e
uniforme para autenticação de passwords dentro de qualquer aplicação
root. Também pode ser útil para a instalação de aplicações futuras tais
como o login, ftpd e pop3d.
Ao contrário de seus antecessores o qmail possui vários daemons executados
com relação de confiança entre eles, cada um possui funções e usuários de controle
diferentes. Existe apenas um daemon no sistema qmail que é gerenciado pelo usuário
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
permissão especial SUID, tornando assim o qmail mais seguro ainda ao nível 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 possível
problema isolado do resto dos serviços.
O qmail possui basicamente 6 usuários destinados ao controle de cada um de
seus daemons, nenhum destes usuários possui um shell real tornando assim o sistema
mais seguro. Os usuários e grupos do qmail são os seguintes:

alias : Este usuário é responsável por controlar todos os aliases do
sistema. Existe de forma análoga ao servidor sendmail e possui a mesma
estrutura dando assim total suporte ao sistema sendmail.

qmaild : Este usuário é utilizado para executar o servidor tcp especial do
qmail chamado tcpserver.

qmaill : Este usuário é utilizado pelo daemon splogger, responsável por
logar toda e qualquer atividade ao daemon padrão de logs do Linux, o
syslogd. É através do splogger que o qmail consegue enviar logs ao
sistema Linux.

qmailq : Este usuário é utilizado para executar o daemon qmail-clean,
responsável por eliminar mensagens e usuários de email que estejam na
memória do servidor com relay ainda aberto.

qmailr : Este usuário é utilizado para executar o daemon qmail-rspawn,
responsável por enviar mensagens para servidores remotos.

qmails : Este usuário é 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 usuário é utilizado para executar os daemons qmail-queue
qmail-lspawn, responsável por enviar mensagens para o servidor local.
Seu funcionamento é bem simples seguindo sempre uma linha lógica 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 conexões de servidores de correio remotos e encaminha estas mensagens
para o daemon qmail-queue, resposável pela gerência da fila de mensagens do
sistema qmail. Da mesma forma temos o daemon qmail-inject que recebe conexões
locais e envias suas mensagens para o daemon qmail-queue. O qmail-queue gerencia
a fila de forma a entregar suas mensagens, através do daemon qmail-send, para os
MTA remoto. O qmail-send é responsável 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 usuário local.
5.3. Licença de Uso
O qmail possui uma licença de uso especial. O qmail pode ser alterado de
qualquer forma possível a melhorar seu funcionamento porém seus pacotes não podem
ser redistribuidos com estas alterações se não foram explicitamente aprovados por seu
desenvolvedor, Dan J. Bernstein. Isso quer dizer que pela sua licença, mesmo que seja
feita alguma alteração em seu código, ele deve ser distribuido intacto.
5.4. Problemas existêntes
O qmail não possui desenvolvimento de seu código, por seu criador, desde o ano
que foi criado em 1996, devido a isto ele não está em conformidade com os
paradigmas atuais de servidores de e-mail no que tange à novas funcionalidades e
softwares existentes. Para tanto é necessário utilizar patches para correção e
implementação dessas funcionalidades bem como utilização de outros programas para
tornar o qmail um ambiente de servidor de e-mail completo e atual.
O problema está na existência de diversos patches e softwares diferentes para a
implementação das mesmas funcionalidades, gerando assim uma redundância. Estes
softwares muitas vezes não são compatíveis entre sí causando problemas quando da
compilação do código do qmail. Para adequar o qmail aos novos paradigmas de
segurança e funcionalidades estas melhorias em seu código, via software, tornam-se
madatórias, portanto é impossível conseguir um qmail realmente adequado a esses
novos paradigmas quando utilizado com seu código padrão intalterado. Todas essas
alterações fazem com que não haja padronização na implementação e configuração do
sistema dificultando o trabalho do administrador, visto que cada adminsitrador só
utiliza o necessário para o seu cenário atual, muitas vezes este cenário não exige uma
implementação completa e avaçada do qmail.
É obrigação do administrador do servidor conseguir um grupo de pacotes e
patches estáveis o bastante de modo a não comprometer a performance e segurança do
servidor.
Outro problema é que para se criar um servidor nesses novos paradigmas é
necessário o uso de patches e novos softwares, para tal é necessário integrá-los,
operação esta apenas possível quando compilamos novamente o qmail via código
fonte, o que gera um overhead no tempo de criação de um servidor.
6 – OTIMIZAÇÕES DO SLACKWARE PARA QUBIT
6.1. Pacotes utilizados e descartados
A distribuição Slackware é composta por 3 CDs de instalação dos quais apenas
os dois primeiros são utilizados para uma instalação padrão. No caso de uma
instalação no perfil desktop é interessante instalar o Slackware Linux com todos os
pacotes, na qual os dois primeiros CDs são necessários totalizando assim 1.2 Gb de
espaço em mídia que pode ser gravado em CD ou DVDs. Se esta instalação for feita
adicionando-se os softwares contidos no último CD ela totalizará um espaço de 1.9 Gb
entre softwares e bibliotecas.
O escopo deste trabalho é desenvolver uma distribuição voltada a utilização de
servidores de e-mail portanto não se torna necessário a instalação de pacotes fora do
deste escopo. Foram excluidos da distribuição Slackware os pacotes dos seguintes
escopos:

Serviços :
Foram descartados todos os pacotes relativos a servidores
não utilizados como sendmail, servidores de impressão, fontes,
roteamento entre outros. Houve também a exclusão de serviços
considerados superdaemon como inetd e xinetd instalados por padrão
nas distribuições Linux para levantar e derrubar por demanda serviços
configurados. Este superdaemon foi substituido pelo ucspi-tcp utilizado
para o mesmo fim em relação aos daemons do sistema qmail. Os serviços
inetd e xinetd produzem um grande overhead para executar serviços
diminuindo também assim a performance do servidor no que tange a
utilização de CPU e Memória RAM para outros serviços.

Softwares e Bibliotecas: Foram excluidos todos os softwares e
bibliotecas relativos a aplicações não condizentes com o cenário atual
como bibliotecas gráficas, svga, seejpeg, seebmp, aplicativos e
bibliotecas de som, ferramentas para cálculo matemático, player de som
e bibliotecas relativas.

Redes : Foram também excluidos softwares para interconectividade de
redes não pertinentes ao projeto como wireless, bluetooth, e suas
bibliotecas.

Ambiente Gráfico : Todo e qualquer pacote relativo a servidores de
ambiente gráfico, Xfree86, Xorg, bem como ambientes gráficos como
KDE, GNOME entre outros foram excluidos. Todos os aplicativos que
executam nestas plataformas também foram excluidos. Enfim foram
excluidos todos os pacotes relativos aos grupos Y, X, XAP, TCL, T,
KDE e KDEI. Esta operação resultou na redução de praticamente 500Mb
da instalação. Estes pacotes foram excluidos por não serem necessários à
um servidor de e-mail e também por reduzirem a performance do mesmo.
6.2. Empacotamento de softwares
Devido a necessidade de otimização de certos pacotes na rede, bem como a
criação de outros, por motivos de performance e redução no tempo de instalação dos
mesmos, foram criados pacotes para todos os softwares utilizados no projeto. Para a
adequação ao modelo de empacotamento do slackware e também para manter a
compatibilidade foram utilizados softwares específicos do próprio sistema para o
empacotamento como pkgtool, makepkg, installpkg, checkinstall, bem como
ferramentas e bibliotecas de compilação padrões da linguagem C como make, gcc e
glibc.
No ato da compilação do software via código fonte podem ser passados
parâmetros para que algumas de suas características sejam alteradas como diretório de
configurações, diretório de armazenamento dos binários gerados, diretório onde serão
localizadas as bibliotecas utilizadas pelos binários, entre outros. Para não
comprometer a estrutura de cada um dos pacotes, levando assim à um possível
problema de quebra de dependência em suas bibliotecas compartilhadas, não foram
alteradas características em relação a pacotes já existentes na distribuição, com apenas
3 excessões em relação aos pacotes apache, php e mysql. Todas as outras alterações
foram feitas em relação aos arquivos principais de configurações instalados para cada
pacote padrão.
A criação de pacotes infere duas operações diferente, uma para pacotes préexistentes onde apenas são alterados os arquivos de configuração e alguns diretórios, e
para pacotes não existentes onde é preciso compilar, e antes da instalação, criar os
pacotes para instalação conforme softwares de empacotamento padrão do sistema.
Na primeira opção, modificação de pacotes pré-existentes, primeiramente o
conteúdo do pacote é extraido usando-se ferramentas de compactação como tar, bzip
e gzip. Depois de toda e qualquer alteração executada deve-se gerar novo pacote com
os comandos citados no parágrafo anterior. O processo de criação para pacotes já
existentes pode ser visualizado por completo no bloco texto abaixo:

Alteração de pacotes compilados do código 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 alteração necessária
root@root /root # makepkg pacote.tgz

Alteração 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 alteração necessária
root@root /root # makepkg pacote.tgz
6.3. Menus Interativos de Instalação
O Slackware Linux possui uma instalação bem intuitiva e leve em relação às
instalações dos demais linux existentes. Ela é baseada inteiramente em script criados
em shell (Shell Scripting) utilizado a biblioteca Ncurses responsável por desenhar
todas as telas de modo a otimizar e facilitar a instalação. O slackware faz uso também
da ferramenta dialog, que através da biblioteca ncurses, serve de front-end para
configuração de menus e mensagens na instalação.
Todo e qualquer menu de instalação criado na distribuição Qubit Linux manterá
este mesmo padrão. Não é objetivo deste projeto criar menus interativos complexos ou
visualmente mais agradáveis. Nosso objetivo em relação à estes menus é implementar
diversas funciolidades básicas necessárias inexistentes no Slackware.
6.3.1. Particionamento Manual e Automático
Por padrão qualquer Linux para ser instalado deve ter primeiramente sua midia
de instalação (Hard disk, Pen drive entre outros) particionada de forma a receber o
sistema. Este particionamento pode ser executado de forma automática ou manual no
ato da instalação de diversos linux via menu interativo normalmente utilizando
diskdruid , parted, entre outros como respectivamente nos Linux Redhat Enterprise e
Slax. O Linux slackware não possui menu interativo para particionamento na
instalação o que gera a necessidade de fechar o terminal de instalação e particionar o
hard disk manualmente através da interface de console via shell.
Para o particionamento podem ser utilizados basicamente dois particionadores
destrutivos : fdisk e cfdisk. A diferença entre eles se deve a maior intuitividade do
cfdisk em relação ao fdisk. Devido a sua intuitividade e facilidade de uso o cfdisk foi
o particionador escolhido para este projeto.
Outra funcionalidade básica inexistente no Slackware é a re-leitura da tabela de
partições após um particionamento bem sucedido, forçando assim ao usuário que
execute um boot no servidor para que ela seja relida e reconhecida pelo processo de
isntalação do sistema linux em questão. Esta operação é executada pelo comando
PARTPROBE inexistente nas versões 10.2 e 11 do Slackware Linux. O software
partprobe foi instalado como um meio de dinamizar a instalação evitando a perda de
tempo no reboot do servidor e também a saida da interface de menus interativos para
sua execução. A adição deste software culmina com um ganho de tempo de
aproximadamente 5 minutos de boot.
Foi desenvolvida uma interface responsável pela configuração visual tanto
automática como manual da etapa de particionamento. Este menu foi feito em duas
etapas, primeiramente verificamos a existência e qual o tipo de hd existe no servidor
bem como sua localidade na controladora IDE/SATA/SCSI em questão. Foi
desenvolvido um script em Shell Script para este fim utilizando-se expressões
regulares. É assim gerada uma lista com diversos dispositivos encontrados pela
inicialização da instalação com dados passados pela BIOS (Figura 3). Para geração
desta lista é consultado o arquivo /proc/partitions em busca de partições encontradas
pelo próprio sistema, através deste arquivo é gerada uma lista de opções para a
escolha do hard disk utilizado na instalação. Esta lista é então desenhada pela
ferramenta dialog que utiliza as bibliotecas ncurses para criação de menus interativos
via shell. É desenhado portanto o menu de escolha de particionamento que possui duas
opções: Particionamento Automático e Particionamento Manual (Figura 4). Para o
menu de Particionamento Automático ainda existem dois perfis utilizados onde apenas
o primeiro é o escopo deste projeto. Este particionamento automático 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 Automático
Verifiquem que o escopo de particionamento em nossa distribuição é apenas de
Hard Disks baseados em controladores IDE/SATA. Não foram feitos testes extensivos
para Hard Disks em controladoras SCSI embora o kernel utilizado ofereça este
suporte.
6.4. Kernel e Patches
O kernel, também chamado de núcleo, é o cerne do sistema, ele é responsável
por verificar e controlar dispositivos de hardware, controlar interrupções, acesso à
memória e ao discos, implementação e verificação de segurança, gerência de sistemas
de arquivos, detecção e correção de falhas nos hardwares, entre outras funções. Para
tanto é necessário 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 versão 2.6.21.5. Chamamos de
kernel vanilla os kernels padrões encontrados no repositório central de kernels para
Linux (www.kernel.org) . A diferença é 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.0
Há uma discução intensa entre a comunidade e o mercado corporativo sobre
qual sistema de arquivos utilizar. Este vai depender do escopo da solução 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 são
EXT2, EXT3, ReiserFS e XFS. Existem diversas diferenças entre cada um deles.
O sistema de arquivos EXT2 é por natureza um dos mais rápidos por não 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 porém com suporte à journaling.
Historicamente falando os sistemas mais utilizados, por serem mais antigos e
maduros, são os EXT2 e EXT3. Recentemente vem sendo muito empregado em
servidores de aplicação crítica, outro sistema de arquivos mais robusto e seguro
chamado ReiserFS. Este sistema de arquivos já foi desenvolvido com suporte padrão à
Journaling e é baseado na estrutura de arvores B, ganhando assim muita performance.
Sua versão estável, e mais utilizada, é a 3.6 pois vem suportada pela maioria dos
kernels em várias distribuições Linux atuais. Recentemente foi desenvolvida uma
nova versão muito superior a esta em vários quesitos. Podemos consultar os dados de
cada um dos sistemas de arquivos nas tabelas abaixo:
Limits
File Systems
EXT2
EXT3
ReiserFS
4.032 bytes / 255
Characterers
Reiser4
Maximum Filename
Length
255 bytes
255 bytes
Allowable Caracters in
Directory Entries
Any expect
NUL
Any expect
NUL
Any expect NUL
Any expect and
NUL
Maximum Pathname
Length
No Limit
Defined
No Limit
Defined
No Limit Defined
No Limit Defined
Maximum File Size
2 Gb to 1 Tb
16 Gb to 1 Tb
8 Tb
8 Tb to 16 Tb
Maximum Volume Size
2 Tb to 32 Tb
2 Tb to 32 Tb
8 Tb to 32 Tb
Indefinido
Tabela 5 – Limites de sistemas de arquivos
3.976 bytes
Metadata
File Systems
EXT2
Yes
EXT3
Yes
ReiserFS
Yes
Reiser4
Yes
Posix file permissions
Yes
Yes
Yes
Yes
Creation Timestamps
Yes
Yes
Yes
Yes
Last Access / Read
timestamps
Yes
Yes
Yes
Yes
Last metadata change
timestamps
Yes
Yes
Yes
Yes
Stores File owner
Last archieve timestamps
No
No
No
No
Access Control Lists
Yes
Yes
Yes
Yes
Security / MAC Labels
Yes
Yes
Yes
Yes
Extended Attributes /
Alterante Data streams /
Forks
Yes
Yes
Yes
Yes
Checksum / ECC
No
No
No
No
Tabela 6 – Metadata de sistemas de arquivos
Features
File Systems
Hard Links
EXT2
Yes
EXT3
Yes
ReiserFS
Yes
Reiser4
Yes
Soft Links
Yes
Yes
Yes
Yes
Block Journaling
No
Yes
Yes
Yes
Metadata-only Journaling
Yes
Yes
Yes
No
Case-sensitive
Yes
Yes
Yes
Yes
Case-preserving
Yes
Yes
Yes
Yes
File Change Log
No
No
No
No
Internal Snapshotting /
Branching
No
No
No
No
XIP
No
No
No
No
Filesystem-level encryption
No
No
No
No
Tabela 7 – Funcionalidades de sistemas de arquivos
Podemos ver claramente que todas as funcionalidades contempladas pelos
sistemas mais antigos são também implementadas no sistema ReiserFS, porém o
ReiserFS possui outras funcionalidades não encontradas em sistemas antigos. A maior
parte dos sistemas vem com suporte a ReiserFS versão 3.6, embora a mais atual seja
4.0. A versão mais atual é mais robusta, tem maior performance na leitura e gravação
de arquivos, bem como suporte a limites bem maiores. Para adicionar o suporte a
versão 4 do sistema de arquivos ReiserFS ao kernel deve-se aplicar um patch.
6.4.2. Patch para BootSplash
Um dos fatores responsáveis pela não adoção do sistema operacional Linux
Slackware é seu caracter pouco intuitivo e, em geral, “seco” do sistema. A
inicialização do Slackware é executada em modo verboso sem nenhuma preocupação
estética com o usuário final. É bom frisar que nem sempre é necessária uma
visualização completa do processo de boot pois o mesmo não pode ser interrompido
de repente para alguma tarefa administrativa no caso de alguma falha, sendo esta falha
só resolvida com a possível necessidade de outro boot. Portanto no caso de algum
erro, os logs do sistema podem ser verificados.
Devido a existência de logs no sistema não há a necessidade de exibir todo erro
encontrado quando da execução de softwares na inicialização, 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 vizualização fica mais simplificada,
intuitiva e limpa para o usuário final bastando apenas, em caso de falha, verificar os
logs para uma saida mais completa.
Para mascarar as mensagens de inicialização 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
visualização de todas as informações de inicialização, deixando assim o processo de
boot menos poluido. Mesmo suprimindo suas mensagens o bootsplash ainda fornece
suporte a modo verboso via tecla de função F2.
7 – HARDENING
7.1. Hardening de Sistema
Atualmente boa parte da quebra de sigilo em sistemas de computação tem como
orígem do ataque funcionários da própria empresa. Estes por estarem dentro da
empresa possuem ferramentas e informações privilegiadas que lhes concedem
conhecimento para executar vários tipos de ataque. Outro fator importante é a relação
aberta de confiança entre a empresa e o funcionário, onde pela visão da empresa o
funcionário é um indivíduo acima de qualquer suspeita.
A situação acima traz consigo um problema, ela termina por deixar os
administradores de serviços e sistemas da empresa mais atentos para o que chega à
seus servidores de fora da empresa, e mais descuidados com o inimigo interno, o
funcionário, abrindo assim uma brecha de segurança condicional.
Independente de confiar ou não em seus funcionários, o administrador deve
executar e manter políticas pesadas de segurança que permitam apenas ao
administrador, e pessoas autorizadas, a utilizarem ou “chegarem” a determinado
servidor ou serviço. Quando acessamos remotamente ou localmente um servidor, ou
seja, quando possuimos um shell neste servidor mesmo não possuindo privilégios de
usuário administrador (usuário root) e consequentemente não executando escritas em
quase nenhum arquivo do sistema, o usuário normal também tem privilégios de leitura
em vários aspectos do servidor permitindo assim uma quebra de sigilo parcial.
Alguns arquivos do sistema pedem atenção especial. Arquivos que armazenam
informações de usuário, grupo e suas senhas, respectivamente
/etc/passwd,
/etc/shadow, /etc/group, /etc/gshadow, devem ser retiradas as permissões para o
grupo other de modo que apenas o usuário e grupo do root tenha acesso ao arquivo e
nenhum outro.
Foram executadas as mesmas alterações nos arquivos de configuração nos
serviços de agendamento de tarefas periódico e aperiódicos, respectivamente CRON e
AT. Seu conteúdo recebeu a linha de configuração “root” permitindo apenas que o
usuário root possa agendar tarefas no sistema, deste modo controlando também as
tarefas que porventura sejam agendadas para outros usuários.
Em sistemas Linux todos os usuários, por padrão, podem executar
reinicialização da máquina com a combinação de teclas CRTL+ALT+DEL, isto
implica na possível indisponibilidade de um servidor caso haja um usuário mal
intencionado. Para inibir este problema foi comentada no arquivo /etc/inittab a linha
responsável por esta funcionalidade que compreende a configuração “ca::crtlaltdel:”.
O reinicialização do sistema deve ser executada apenas pelo usuário root mediante
execução dos comandos halt, reboot ou init 6.
Para permitirmos que determinado software execute com as permissões de outro
usuário, usamos um bit especial chamado SUID. Muitos comandos no Linux possuem
este bit ligado desnecessáriamente ocasionando assim uma possível falha de
segurança. Portanto esta permissão 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 disponíveis na instalação. Embora em modo single user seja utilizado
apenas um, em modo multi user estão disponíveis 6 terminais tty1 à tty6, e mais um
especial para a execução do ambiente gráfico. Não há necessidade de existirem tantos
terminais pois o superusuário trabalha apenas com 1 ou 2 ao mesmo tempo, e também
pelo fato de que um terminal aberto, mesmo não utilizado, consome memória do
servidor reduzindo sua performance.
Portanto foram eliminados os terminais tty3 à tty7, restando apenas tty1 a tty2
para interação com o usuário. Estas alterações foram executadas com o comando sed
para a substituição de strings em um arquivo.
Outra medida de segurança tomada foi a alteração e exibição de banners para
login local e remoto de usuários. O banner alterado é exibido sempre no início de cada
conexão ou login, antes do preenchimento de nome de usuário 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 Serviços
Atualmente grande parte da quebra de sigilo e invasões a sistemas domésticos 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 não prevista abrem uma porta de entrada
para um intruso em potencial. A customização de serviços de login remoto e locais do
servidor que possuam algum suporte a rede chamamos de Hardening de Serviços.
7.2.1. SSH e Serviços de Acesso Remoto
Pode-se afirmar que praticamente todo acesso remoto utilizado para manutenção
ou desenvolvimento de um servidor atual é feito via shell seguro, mais conhecido
como ssh. Desta forma criamos uma camada a mais de proteção pois neste caso o
meio é criptografado impossibilitando assim a captura e leitura de pacotes por ataques
man-in-the-middle. Porém o ssh, por ser o serviço de login mais amplamente
utilizado, também é um dos mais expostos a falhas devido a falta de configuração
necessária para protegê-lo de forma eficiênte. Em nossa implementação foram
adotadas todas as medidas sugeridas pela NSA (Agência de Segurança Nacional
Americada) relativas ao ssh.
O ssh, ou Secure Shell, aceita conexões de protocolo TCP no socket 22. Existem
atualmente dois protocolos suportados, versão 1.0 e 2.0, entre outras de passagem,
sendo a 2.0 mais atual. Por padrão o ssh responde primeiramente por requisições de
clientes 2.0, uma vez não encontrando clientes nesta versão o daemon altera
automáticamente a requisição para 1.0, dentro de uma sequência lógica préconfigurada,
afim de
suportar vários protocolos.
A versão 1.0 é considerada
insegura, tendo sofrido vários problemas relacionados à exploits e obtenção de acesso
remoto root via ataques de buffer overflow. Utilizamos portanto apenas a versão 2.0,
forçando a utilização de clientes com suporte a versão mais nova aumentando a
segurança do serviço. Esta opção é configurada pela linha “Protocol 2”.
Para melhor esclarecer o usuário responsável pela conexão remota sobre as
políticas atuais de segurança do servidor, a primeira ação tomada é a exibição do
mesmo banner anterior, /etc/issue, no início de qualquer conexão remota como um
aviso.
Outro fator que contribui para o aumento da probabilidade de um ataque é o fato
de que o ssh por padrão não limita acessos por usuário ou número de conexões,
portanto permitindo acesso remoto ao usuário root quantas vezes forem requisitados.
Mesmo que um atacante desconheça a senha, através de um ataque brute force ou
wordlist ele está livre para tentar indefinidamente.
Para inibir este tipo de ataque ao daemon foi criado o usuário de sistema
“admin” responsável por todo e qualquer login remoto ou local, portanto apenas ele
tem authorização, configurada pela tag “AllowUsers admin“. Uma vez vetado o
acesso remoto ao usuário root a configuração pertinente também foi excluida com a
linha “PermitRootLogin no“. Para o limite de logins foi configurada a linha
“MaxAuthTries 5“, setando em 5 o número máximo de autenticações por minuto. Em
caso de erro de senha 5 vezes seguindas o usuário é automaticamente bloqueado,
exigindo assim intervenção local no servidor para a resolução de problemas.
Não é permitida também a autenticação de usuários com senhas vazias, mesmo
que
elas
existam.
Esta
“PermitEmptyPasswords no“.
funcionalidade
é
configurada
pela
opção
Como a distribuição Qubit não possui ambiente
gráfico não foram permitidas as configurações para o servidor X11, setadas pelas
opções “AllowTcpForwarding no“ e “X11Forwarding no“.
Grande parte dos ataques ao ssh são derivados de Denial of Service, onde o
servidor recebe uma enxurrada de pacotes inundando suas requisições terminado por
não conseguir mais respondê-las. Este ataque termina por derrubar o servidor ou
deixá-lo indisponível por horas, as vezes dias. Alguns destes ataques podem ser feitos
após 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
usuário, deste modo aumentando a performance e diminuindo a probabilidade de
danos. A configuração de cada um dos usuários remotos não root foi feita com o
conceito de chroot jail (cadeia), pela configuração “UsePrivilegeSeparation yes“.
Com isso asseguramos uma separação de privilégios onde o daemon é dividido em
duas partes onde uma pequena quantia do código 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 segurança foram vetados todos os métodos de autenticações
baseadas em hosts como autenticação primária utilizando as configurações:
IgnoreRhosts yes, HostbasedAuthentication no, RhostsRSAAuthentication no.
Estas autenticações, embora funcionem por túnel criptografado, não possuem senha,
por isso são baseadas em hosts. Por não possuirem senha mostram-se ineficazes aos
paradigmas de segurança atuais. A configuração 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. Comparação entre versões e padrões atuais
O desenvolvimento de uma solução completa de servidor de emails varia
principalmente devido ao escopo de utilização do administrador que o desenvolve.
Não há a necessidade de implementação de um software desnecessário no sistema.
Com isso são gerados diversos padrões de instalação do qmail, sendo os mais
conhecidos atualmente: qmailrocks, life with qmail, nrg4u e John Simpson.
A medida que cresce a demanda por aplicações no escopo de segurança, bem
como adição de funcionalidades adequando os servidores de e-mail aos paradigmas
atuais, surge também uma gama de programas, muitas vezes redudantes, para uma
mesma função no sistema. Isto acarreta problemas de pois temos diversos programas
que resolvem os mesmos problemas implementados com diversas linguagens que são
normalmente incompatíveis entre sí. O conjunto de programas utilizados por um
administrador também varia de acordo com o escopo. O mesmo acontece em relação
aos patches para adição de novas funcionalidades.
Cada um dos padrões 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 segurança
corporativo devemos fornecer um grupo concreto de programas e patches à solução de
e-mail de forma que execute com segurança e performance.
Existem basicamente duas versões do qmail, qmail-1.03 e netqmail-1.05. na
verdade a versão netqmail nada mais é do que a versão original 1.03 com 8 patches
recomendados. Neste projeto foi utilizada a versão original junto com outro conjunto
de patches que incluiem os 8 recomendados pelo desenvolvedor entre outros 50. Em
todos os outros padrões é utilizado o netqmail.
Para este projeto foi adotado o patch de funcionalidades combinado, de Tino
Reichardt. Este patch possui adequação do código do qmail à diversas RFCs mais
atuais, que outros patches dos padrões anteriores não fornecem, portanto deixando o email em conformidade com todos os novos paradigmas e RFCs de e-mail.
Todas as configurações do qmail localizam-se no diretório /var/qmail/control,
onde cada uma delas podem também ter diversos outros diretórios, detalhados no
capítulo XX sobre padronizações da distribuição. Abaixo são listados os patches e
medidas de segurança implementados por eles:
8.2. Medidas Anti-Spam
Algumas medidas anti-spam podem ser tomadas sem a necessidade de utilização
de um software para anti-spam como clamav etc. Diversas novas funcionalidades
podem ser inseridas por meio de patches.
São frequentes envios de e-mail para destinatários vazios fazendo com que a
mensagem não consiga ser entregue ocupando processamento da máquina. Com um
patch especial podemos exibir a mensagem de erro “221 2.0.0: I can break rules, too.
Goodbye” e fechar a conexão estabelecida caso um cliente envie um comando DATA
(abertura de corpo da mensagem) mas nenhum campo RCPT TO (destinatário da
mensagem) eliminando perda de performance.
Com
o
patch
P0f,
controlado
pelo
arquivo
de
configuração
/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 máquinas que conectam no servidor
(SYN mode), conexões do servidor para máquinas cliente (SYN+ACK mode),
máquinas que não podem ser conectadas (RST+ mode) e máquinas que desejamos
observar a comunicação. Podemos ainda, devido ao fingerprint, detectar a presença de
firewall, Nat, Load Balancer, distancia ao sistema remoto e seu uptime (Tempo em
execução), e redes como DSL, OC3 (Cisco) entre outras.
Quando um determinado email é enviado para determinado destinatário, a
existência deste só é checada quando do recebimento do e-mail ao servidor destino,
caso a conta de e-mail destinatária não exista no domínio a mensagem retorna
informando que a caixa destino é inexistente, isto gera um problema de performance
visto todos os e-mails, reais ou não, serem enviados desnecessáriamente do servidor
ocasionando gasto excessivo de tráfego. Com o patch realcrptto toda e qualquer
mensagem tem seu campo RCPT TO checado localmente e remotamente, caso o
destinatário não exista a mensagem é automaticamente descartada.
Foi também implementado outro patch para a verificação de remetente e
destinatário no mesmo formato que o patch realrcptto, que pode ser controlado no
arquivo de configuração /var/qmail/control/rcptcheck. Neste arquivo configuramos
a lista de SENDERs e RECIPIENTS que devem ser verificados. Por motivos melhoria
de performance os mesmos valores podem ser configurados via variáveis do sistema,
respectivamente $SENDER e $RECIPIENT de forma a aumentar a velocidade do
serviço. As seguintes mensagems de retorno foram implementadas:
1 -> "553
2 -> "421
3 -> "421
11 -> "451
12 -> "451
13 -> "451
14 -> "451
16 -> "451
17 -> "451
18 -> "451
21 -> "452
22 -> "452
111 -> "421
112 -> "421
(greylisting)"
5.1.1
4.3.0
4.3.0
4.1.1
4.1.2
4.1.3
4.1.4
4.1.6
4.1.7
4.1.8
4.2.1
4.2.2
4.3.0
4.3.0
sorry, no mailbox here by that name."
unable to verify recipient/sender (misuse)"
unable to verify recipient/sender (internal)"
bad destination mailbox address"
bad destination system address"
bad destination mailbox address syntax"
destination mailbox address ambiguous"
mailbox has moved"
bad sender's mailbox address syntax"
bad sender's system address"
mailbox disabled, not accepting messages"
mailbox full"
unable to verify recipient/sender (temporary)"
unable to verify recipient/sender
Neste mesmo patch podemos também implementer o conceito de graylist onde
vetamos a utilização de nosso servidor por um determinado domínio, por padrão,
porém permitindo determinada conta deste mesmo domínio, de forma a criarmos um
controle mais complexo.
Também foram implementadas blacklists baseadas em remententes e
destinatários,
respectivamente
configuradas
pelos
arquivos
/var/qmail/control/badmailfrom e /var/qmail/control/badmailto, onde vetamos a
entrada ou saida de um determinado e-mail, domínio ou padrão de mensagem préestabelecida, sem a utilização de antivirus. Podemos ainda implementar veto de
mensagens
de
anúncio
de
servidores
ou
clientes
pelo
arquivo
/var/qmail/control/badhelo bastando listar linha a linha, assim como os arquivos
supracitados, os nomes não autorizados a se anunciarem ao servidor. É importante
frisar que os arquivos badmailfrom, badmailto, badhelo e goodmailto podem
utilizar expressões regulares para expor determinado padrão ao filtro, poupando assim
um imenso trabalho de manutenção do administrador.
Podem haver ocasiões onde um e-mail é enviado para um determinado domínio
que não publique registros MX, próprios de email. A maioria dos servidores de email
existentes não executa esta checagem, causando perda de banda desnecessária.
Podemos realizar esta tarefa através de checagens de registros DNS próprios para
servidores de email baseados no patch mfcheck, controlado pelo arquivo
/var/qmail/control/mfcheck, onde a entrada simples de 3 valores diferentes referense à ação tomada mediante sucesso ou erro da verificação. Os valores são:
0: Nenhum dns-check é feito
1: Apenas são checadas entradas MX/A do DNS
2: - Um teste testbounce é enviado ao MX remoto do domínio do
rementente
- Permanentemente ignora os IPs, que serão listados no arquivo
/var/qmail/control/mxblacklist, aguardando intervenção do
administrador para liberá-los.
Todos os Ips de domínios que porventura forem checados e vão para a lista de
mxblacklist serão listados no arquivo /var/qmail/control/mxblacklist. Esta lista,
embora normalmente populada automaticamente pela checagem de dns implementada
por patch, pode ser também manualmente alimentada.
Por padrão para que uma mensagem não fique na fila durante muito tempo, e por
diversas vezes vetando assim e-mails de supostos atacantes com datas erradas de
envio usamos o patch datecheck para checagem de data. Assim como os demais ele
funciona com regexp que pode ser utilizada para definir um padrão de data a ser
checado. Por padrão as mensagens aguardam 7 dias na fila caso seu destino nào seja
encontrado por vários motivos, só então quando não for encontrada a mensagem
retorna.
Caso haja o antivirus ClamAV não esteja instalado no servidor podemos
fornecer o IP de seu servidor para consulta e verificação de virus. Esta funcionalidade
não existe para nenhum outro MX, fazendo com que seja madatória a instalação de um
antivirus no servidor, ocasionando uma drástica queda de performance.
Podemos agora também consultar listas de blacklists de outros provedores ou
servidores globais de blacklists através do software rblsmtpd implementado em nosso
software. Sua configuração é feita alterando-se o arquivo de envio de email, e
inserindo-o antes da fila de saida do daemon qmail-smtpd seguido de sua lista de
verificação, como abaixo:
/command/rblsmtpd -C -t 10 \
-r "cbl.abuseat.org:Sorry. You are listed in cbl.abuseat.org ..." \
-r "sbl.spamhaus.org:Sorry. You are listed in sbl.spamhaus.org ..." \
-r "xbl.spamhaus.org:Sorry. You are listed in xbl.spamhaus.org ..." \
8.3. Medidas de Autenticação e Segurança
Em todos os padrões anteriores são utilizados patches para a implementação de
segurança via criptografia de dados bem como autenticação forçada. O patch mais
comumente utilizado é do desenvolvedor John Simpson. Os patches funcionam sem
demais problemas, porém possuem deficiências básicas. Quando passamos um patch
diretamente ao código do qmail, é necessária uma recompilação para que os binários
sejam novamente construidos e a nova funcionalidade seja executada. O patch para
criptografia e autenticação forçada de John Simpson não possui controle via arquivos
de texto modularizados, portanto caso o administrador queira desligar a feature, ou
usar whitelists para permitir que determinados usuários possam logar sem senha o
código fonte do qmail deve ser novamente recompilado, gastando assim um tempo
valioso pois durante a operação o serviço deve estar indisponível.
John Simpson implementa apenas alguns tipos de criptografia em seus patches,
qualquer outra deve ser implementada por outro conjunto de patches. Tino Reichardt
desenvolveu um patch combinado com diveros protocolos de autenticação adequando
assim o qmail a diversos RFCs. Todos os seus patches tem configuração baseada em
arquivos texto para cada tipo de serviço. Uma lista de todos os pachtes pode ser
visualizada no anexo 1.
Todos os arquivos de configuração relativos a tipos de criptografia aceita por
smtp e pop são populados via um código de base 2, onde o número de entrada é
sempre um valor somado de uma potência de 2. Seguindo a tabela abaixo
conseguimos atribuir facilmente uma configuração antes fixa, de forma modular
apenas somando-se os valores para cada tipo de autenticação:
LOGIN
PLAIN
CRAM-MD5
CRAM-SHA1
CRAM-RIPEMD
DIGEST-MD5
= 1
= 2
= 4
= 8
= 16 (RIPEMD-160)
= 32
Os arquivos control/auth/pop3, control/auth/spop3, control/auth/smtp e
control/auth/smtps podem por exemplo ter o valor 63 que é a soma de todos os
suportes da tabela acima. Vemos que desta forma modular é mais facil e simples
administrar os sistema. Cada conexão ao serviço protegido o daemon responsável,
qmail-smtpd, analisa o arquivo via filtros de REGEXP e verifica qual o tipo de
suporte a conexão o servidor tem suporte.
Uma medida de segurança tomada nos serviços foi vetar a possibilidade de login
sem limite de tempo sobre as tentativas de login errado. Foi implementado patch,
configurado pelo arquivo texto /var/qmail/control/auth/delay que informa que
depois de cada erro de senha quanto tempo o servidor irá aguardar para receber a
mesma requisição do cliente novamente. Isto reduz o overhead do servidor e também
impossibilita uma tentiva infinita de DDOS ou Brute Force para verificação de senha
de alguma conta existente. O conteúdo de configuração deste arquivo é dado em
segundos.
8.4. Medidas de Testes para badmail
Conforme citado no capítulo 8.2 sobre medidas anti-spam, conseguimos agora
vetar diversas funcionalidades para clientes que não se adequem ao padrão
configurado. No arquivo /var/qmail/control/badhelo vetamos o anuncio de clientes
com determinadas strings para o comando HELO/EHLO, com isso também obrigamos
o cliente a se identificar para começar uma sessào de email, funcionalidade não
existente no postfix ou sendmail. Com o comando EHLO no smtp podemos verificar
todos os tipos de autenticação do servidor. Isto é muito importante quando temos um
servidor onde apenas a rede interna de uma empresa acesse, mesmo que ele se
encontre na DMZ onde naturalmente terá IP público. Toda mensagem negada receberá
a resposta de erro “553 5.7.1 sorry, your helo or ehlo is incorrect”.
No arquivo /var/qmail/control/badmailfrom podemos criar uma blacklist de emails, domínios e padrões definidos por expressões regulares que não queremos
receber, por exemplo para bloquear qualquer email vindo do dominio @ig.com.br pela
linha „*@ig.com.br‟. Toda mensagem bloqueada recebera o erro “553 5.7.1 sorry,
your envelope sender has been denied. No arquivo /var/qmail/control/badmailto são
configurados os mesmos valores, com os mesmos padrões em relações aos emails
destinados a determinado e-mail, dóminio ou padrão estabelecido por regexp. Toda
mensagem negada receberá a resposta de erro “553 5.7.1 sorry, your envelope
recipient has been denied”.
No arquivo /var/qmail/control/goodmailfrom podemos gerar uma whitelist
contendo emails ou domínios que sempre serão aceitos no relay do servidor, mesmo
que ele se aplique à alguma regra restritiva do servidor.
8.5. Medidas para melhorar mensagens de Status
Quando encontramos algum erro de mensagem, devido a não adequação do
código do postfix e sendmail às novas mensagens de erro, implementadas por RFCs
mais novos, não conseguimos resolver de forma segura o problema em sí. Nesta
distribuição o código do qmail foi adequado, via patch, as RFCs mais novas sendo
elas RFC1893, RFC2034 e RFC3463, implementando assim todas as mensagens , não
existentes em outros sistemas de email, embora sejam mandatórias em padrões
mundias. A lista de mensagens pode ser visualizada no anexo 2.
8.6. Medidas para Logs de e-mail
Em sistemas postfix, sendmail, exim entre outros, todas as mensagens de log de
sistemas
de
email
são
automaticamente
redirecionadas
um
arquivo
geral
/var/logs/maillog. Centralizando esses logs gera-se um problema de supercrescimento
deste arquivo, uma vez que ele recebera todas as mensagens. Torna-se assim
mandatório uma rotação de logs mais frequentes trazendo queda de performance. Caso
haja problemas o adminsitrador é obrigado a ler o arquivo inteiro em busca do erro,
tendo que filtrá-lo com diversas ferramentas como perl, sed, awk, entre outras,
tornando a identificação, leitura e depuração de logs uma tarefa demorada e custosa.
Neste projeto todos os logs do sistema foram descentralizados e modularizados em
arquivos diferentes para cada serviço dentro de um diretório especial fora do padrão
de logs do linux (/var/logs). Implementamos o diretório /var/qmail/control/log, via
patch qmaillog, no mesmo diretório de arquivos de controle do qmail como forma de
padronizar a distribuição. Neste diretório encontram-se todos os arquivos referentes
aos logs separados pelo nome do serviço referente a ele. Podemos verificar uma lista
destes arquivos no anexo 3:
Baseando-se em arquivos modulares de logs para cada serviço podemos
encontrar mais facilmente as mensagens de problemas requeridas.
9 – SOFTWARES UTILIZADOS PARA SERVIÇOS
9.1. Ezmlm e Ezmlm-idx
Como todo servidor de e-mail, neste projeto também foi incluido um sistema de
gerência para mailing lists. Estes sistema foi desenvolvido por Dan. J. Bernstein e
possui várias funções além de ser um dos mais simples de ser gerenciado. Seu código
é aberto e pode ser alterado sem problemas, mesmo não estando sob a licença GPL.
9.2. Autoresponders
Autoresponder são softwares responsáveis por responder ou reenviar mensagens
de contas de e-mail inativas ou inoperantes. Seu uso principal é a ativação de
mensagens de férias para funcionários ativos ou inativos. O próprio daemon do
serviço trata de responder todas as mensagens que tenham como destino o email do
funcionário, baseado em um padrão pré-configurado em arquivos .qmail no diretório
home da conta de todo usuário. Em nosso sistema foi utilizado o autoresponder do
desenvolvedor Eric Huss por ser o mais adotado mundialmente, fornecendo assim
basntante informação usuário final quando da configuração manual via console, sem
um sistema web.
9.3. Vpopmail
Quando desenvolvemos um sistema de e-mail existem várias estruturas
responsáveis por manter e armazenar caixas postais de usuários. A forma padrão do
qmail chama-se .Maildir. Neste formato as mensagens são armazenadas de duas
formas diferentes, ou todas em apenas um arquivo geral ou cada mensagen cria um
arquivo diferente dentro de uma estrutura pré-determinada. Quando utilizamos este
modelo temos um problema de manutenção visto estas mensagens serem arquivos do
sistema operacional. Caso este mesmo sistema tenha sofrido algum tipo de tunning
para performance e seus inodos tenham sido limitados, podemos ter problemas com
muitas mensagens.
Outro problema proveniente deste sistema é a necessidade de um usuário de
sistema para cada usuário de e-mail, causando assim um enorme trabalho ao
administrador e também ao sistema. O software vpopmail, da impresa Inter7 e de
código GPL, implementa uma estrutura diferente baseada em domínios virtuais onde
os usuários não mais são configurados via /etc/passwd e /etc/shadow, e sim em um
arquivo modular a parte do sistema. Assim o diretório home de cada usuário também
pertence a outra estrutura diferente do diretório padrão /home, no diretório
/home/vpopmail onde cada diretório dentro deste é responsável pelo armazenamento
de mensagens para um determinado domínio, e dentro de cada diretório de domínio
temos portanto diretórios home dos usuários.
O vpopmail também possui suporte à armazenamento e controle de todos os
seus domínios e contas de usuário via banco de dados MySQL e Postgres. A
integração com estes bancos de dados não foi abordada neste projeto e será abordada
em projetos futuros.
9.4. Courier-imap/imaps e Courierpassd
Por padrão o qmail não possui suporte ao protocolo IMAP, embora mais lento é
mais atual e seguro que seu antecessor POP. Para sua implementação foi escolhido o
Courier-Imap/Imaps com código sob a licença GPL. O pacote courierpassd é utilizado
para a integração de webmails com funcionalidades de mundança de senha via
interface web.
9.5. Webmail
Caso o acesso ao servidor nào seja feito via protocolos padrões como POP,
SMTP e IMAP, há a opção do usuário entrar via web em sua caixa independente de
sua localidade. O webmails abordado neste projeto foi o roundcube considerado
rápido e fácil de utilizar. Ele funciona sobre arquitetura LAMP usando Ajax, portanto
economizando banda.
9.6. ClamAV
Atualmente existem vários softwares para verificação de virus em e-mails e
sistema. A grande maioria é copyright, portanto paga, e uma outra grande parcela não
funciona diretamente para Linux. O Antivirus ClamAV foi a opção escolhida para este
projeto por ter arquitetura simples, grande adoção no mercado de software como um
dos melhoers. Ganhando inclusive prêmios por ser o antivirus de software mais rápido
e com mais frequência de atualizações. Este software está sob a licença GPL, podendo
ser distribuido e alterado.
9.7. SpamAssassin
Além das medidas tomadas via patches para spam, foi adotado o software
software Anti-Spam mais conhecido do mundo, Spamassassin. Ele foi implementado
de maneira prática e simples, embora sua configuração não seja muito intuitiva e
realmente bem complexa. Este software será melhor abordado em versões futuras do
sistema.
10 – PADRONIZAÇÃO
10.1. Diretórios e Links
Verificamos que para criarmos um servidor de email completo possuimos vários
aspectos, vários softwares utilizados, cada qual com seu arquivo principal de
configuração localizado em locais diferentes dificultando assim a gerência uma vez
que devemos localizar cada um dos arquivos ao longo do sistema de diretórios do
servidor.
Para evitar esta perda de tempo com localização de diretórios foi desenvolvido
um script chamado rc.qubit_defaults que checa e seta, executando sempre na
inicialização, todos os padrões pertinentes à este projeto.
Foi padronizado e criado o diretório /etc/qubit dentro do diretório principal de
configuração para armazenar os links para todos os arquivos principais de
configuraçào para cada software pertinente ao servidor. Foi criado o link
/etc/qubit/qmail para o diretório /var/qmail/control para agruparmos todas as
configurações do qmail. Foi considerado o diretório /home/vpopmail que armazena o
diretório home das contas de email dos usuários, padronizados no
link
/etc/qubit/qmail/domains. Todos os arquivos de configuração dos softwares
participantes, porém não padrões, do qmail foram armazenados no diretório
/etc/qubit/qmailother. Para todos os outros softwares não relativos a serviço de email
como ssh, ntp entre outros, foram criados links para seus arquivos principais de
configuração e armazenados no diretório /etc/qubit/network. Seus valores foram
padronizados pelo script /etc/rc.d/rc.hardening discutido no capítulo 7.
10.2. Arquivos e Conteúdo
Para eliminar o atraso e gasto de tempo na configuração manual de um servidor
de e-mail qmail, foram atribuidos valores padrões à vários arquivos de configuração
do servidor de email, tanto nos arquivos de configuração geral do qmail ,
/var/qmail/control/, como para outros softwares como spamassassim, vpopmail entre
outros. Todos os arquivos reconfigurados são opcionais e normalmente configurados
manualmente pelo administrador. Os valores abaixo, seguidos da explicação de cada
arquivo, foram extraidos de configurações conhecidas de segurança bem como
orientações e recomendações da comunidade de software livre para criar um servidor
corporativo.
Arquivos de controle geral (/var/qmail/control/):

concurrencyincoming : Arquivo para configuração do número de
sessões remotas concorrentes feitas ao servidor. Valor padrão “200”.

concurrencylocal : Arquivo para configuração do número de sessões
geradas localmente pela rede interna ou localhost do servidor. Valor
padrão “200”.

concurrencyremote : Arquivo para configuração do número de sessões
geradas para outros servidores. Valor padrão “200”.

databytes : arquivo para configuração de tamanho máximo para cada email em bytes. Valor padrão “16384”, ou seja, 20 MB por e-mail.

rcpthosts : Arquivo para a configuração, linha a linha, de domínios
hospedados
localmente
no
servidor.
Este
arquivo
é
populado
automaticamente na criação de um domínio.

morercpthosts : Arquivo auxiliar na configuração, linha a linha, de
domínios hospedados localmente. Para aumento de performance é
sugerido que a configuração de mais de 50 domínios passe a ser feita
neste arquivo, caso contrário o arquivo rcpthosts ficaria grande demais
para ser lido de forma eficaz. „

percenthack : Arquivo de configuração utilizado para corrigir domínios
que troquem o símbolo “@” por “%” como o sendmail. Valor padrão
“%”.

qmpqservers : Arquivo para configuração de redes internas para
balanceamento de carga entre servidores. Utiliza um protocolo especial
do qmail chamado QMPQ, mais rápido que o SMTP. Pode ser utilizado
apenas entre trocas e balanceamento de carga entre servidores qmail.

queuelifetime : Arquivo para configuração de quanto tempo, em
segundos, uma mensagem pode permanecer na fila até ser entregue ou
devolvida. Valor padrào “604800”, ou seja, 7 dias.

smtproutes : Arquivo para configuração de forwarders para domínios ou
emails baseados em regexp. Podemos com o qmail informar que toda e
qualquer mensagen vinda do domínio hotmail.com seja enviada para o
servidor número 3 para que ele a envie para a internet. Podemos assim
criar um controle eficaz de fila diminuindo o número de spam e
aumentando a verbosidade da rede na busca de algum problema.

smtpgreeting : Mensagem de boas vindas exibida para uma conexão
entre servidores ou via telnet. Esta mensagem contém o banner do
serviço qmail, mais conhecido como fingerprinting.

timeoutconnect : Arquivo de configuração que informa ao qmail quanto
tempo, em segundos, esperar por uma conexão SMTP. Valor padrão
“60”, ou seja 1 minuto.

timeoutremote : Arquivo de configuração que informa ao qmail quanto
tempo, em segundos, esperar pela conexão de um servidor. Valor padrão
“1200”, ou seja, 2 minutos.

timeoutsmtpd : Arquivo de configuração que informa ao qmail quanto
tempo, em segundos, esperar pela conexão de um cliente SMTP. Valor
padrão “1200”, ou seja, 2 minutos.

virtualdomains : Arquivo de configuração utilizado para criar domínios
virtuais.
Arquivos de controle para autenticação (/var/qmail/control/auth/):

pop3 : Controle de protocolos de autenticação para o protocolo POP.
Valor padrão “60”, ou seja, ligados os modos DIGEST-MD5, CRAMRIPEMD, CRAM-SHA1, CRAM-MD5.

spop3 : Controle de protocolos de autenticação para o protocolo SPOP.
Valor padrão “60”, ou seja, ligados os modos DIGEST-MD5, CRAMRIPEMD, CRAM-SHA1, CRAM-MD5, PLAIN, LOGIN.

smtp : Controle de protocolos de autenticação para o protocolo SMTP.
Valor padrão “60”, ou seja, ligados os modos DIGEST-MD5, CRAMRIPEMD, CRAM-SHA1, CRAM-MD5.

smtp : Controle de protocolos de autenticação para o protocolo SMTP.
Valor padrão “60”, ou seja, ligados os modos DIGEST-MD5, CRAMRIPEMD, CRAM-SHA1, CRAM-MD5, PLAIN, LOGIN.

delay : Arquivo de configuração para o tempo em segundos entre
tentativas de conexão caso haja um erro de senha do usuário. Valor
padrão “60”.

oldauth : Arquivo de configuração para corrigir falha de antigos clientes
de email microsoft que não finalizam a sessão de e-mail deixando uma
conexão persistente no servidor e assim reduzindo a performance.
Arquivos de controle Anti-Spam (/var/qmail/control/):

p0fsock : Arquivo para configuração de padrões, via regexp, para
verificação passiva de Sistemas Operacionais. Utilizado como filtros de
acesso.

rcptcheck : Arquivo para configuração de software para checagem e
validação de remententes e destinatários.

mfcheck : Arquivo de configuração para checagem de DNS validando
apenas recebimento de emails de domínios que publiquem registros
MX/A de DNS. Valor padrão “1”.

datechecks : Arquivo de configuração para checagem de datas em emails. Sem a utilização deste patch redes como usenet, e mailing lists
podem ficar inoperantes. Valor padrao “qmail-list-:7” checando apenas
por nomes decorrentes de padrões de mailing list.

clamd : Arquivo para configuração de IP do servidor de Antivirus
ClamAV. Valor padrão “127.0.0.1”, setando para o localhost já que o
servidor de antivirus foi instalado no próprio servidor.

mxblacklist : Arquivo de configuração, linha a linha, de MX recusados
pelo servidor. Este arquivo é populado dinamicamente pelo software
rblsmtpd.
11 – CONCLUSÃO
Ao final deste projeto conseguimos desenvolver uma versão beta baseada no
Linux Slackware, Qubit Linux, com uma integração total de praticamente todos os
softwares pertinentes ao funcionamento de um servidor de e-mail atual. Nosso
servidor foi adequado a praticamente todos os RFCs mais atuais no escopo de
servidores de e-mail. Reduzimos o trabalho e tempo de instalação, implementação e
manutenção do administrador de 72 horas para 2 horas em média com a instalação
personalizada e padronizada.
Modularizamos a configuração de todos os aspectos de um servidor de e-mail
em arquivos separados, diferente de outras distribuições onde a configuração é
praticamente toda feita em apenas um arquivo geral. Implementamos diversos outros
serviços de rede como IMAP, Antivírus e Antispams de forma padronizada.
Melhoramos a gerência de todo o sistema padronizando um diretório geral de todas as
configurações necessárias aos serviços de email facilitando e poupando tempo final do
administrador.
O objetivo desta padronização é criar um ambiente favorável à criação de
ferramentas web customizadas para executar todas as tarefas de implementação e
configuração de um servidor de e-mail corporativo, tarefas essas impossíveis
anteriormente devido a falta de padrões de instalação, manutenção e pacotes do
sistema.
12 – TRABALHOS FUTUROS
Criação de interface web baseada em PHP e Ájax AJAX para a administração
total do servidor de e-mail sem a necessidade de recorrer a linha de comando,
poupando assim mais tempo devido a intuitividade das operações e abstraindo a parte
técnica permitindo ao usuário uma configuração eficaz sem a necessidade de um
conhecimento profundo do sistema operacional e sistema de email qmail.. Este
ambiente contará com telas completas de gerência dinâmicas que farão o
monitoramento de vários servidores ao mesmo tempo remotamente via rede.
Tentaremos adequar o qmail de forma a concorrer com outros softwares do
mercado como uma suíte completa de e-mail como LOTUS NOTES e Microsoft
Exchange.
Implementação de mais protocolos de segurança de maneira mais completa
como OpenSSL afim de aumentar a segurança do servidor.
13 - REFERÊNCIAS BIBLIOGRÁFICAS
LEVINE, John. Qmail® – Managing Unix-Based Mail Systems . 2004. Livro
Técnico – O‟Reilly® Media Inc., United States. ISBN 10: 1-56592-628-5, ISBN
13: 9781565926288
COSTA, Felipe. Qmail® Livro técnico prático, de fácil leitura e muitas ilustrações.
2006. Livro Técnico – Editora Ciência Moderna.
SOFTWARE LIVRE. Disponível em: http://www.softwarelivre.gov.br/SwLivre/
[capturado em novembro de 2007].
GNU. Disponível em: http://www.gnu.org/licenses/licenses.html#GPL [capturado em
novembro de 2007].
WIKIPEDIA. Disponível em: http://en.wikipedia.org/wiki/Software_license [capturado
em novembro de 2007].
NSA National Security Agency – Guide to the Secure Configuration of Red Hat
Enterprise Linux 5. NSA, 2007.
MICROSOFT Delivery Guide - Developing Microsoft ASP.NET Web Applications
Using Visual Studio® .NET. Microsoft, 2002.