segurança em correio eletronico
TRANSCRIPT
UNIÃO EDUCACIONAL MINAS GERAIS S/C LTDA FACULDADE DE CIÊNCIAS APLICADAS DE MINAS Autorizada pela Portaria no 577/2000 – MEC, de 03/05/2000 ESPECIALIZAÇÃO EM SEGURANÇA DA INFORMAÇÃO
MARCEL FAGUNDES SOUZA
SEGURANÇA EM SERVIDORES DE CORREIO ELETRÔNICO
Uberlândia
2006
MARCEL FAGUNDES SOUZA
SEGURANÇA EM SERVIDORES DE CORREIO ELETRÔNICO
Monografia apresentada à Faculdade de Ciências Aplicadas de Minas Gerais da União Educacional Minas Gerais (UNIMINAS), como parte das exigências do Título de Especialista em Segurança da Informação.
Orientador: Prof. Msc. Gilson Marques da Silva
Uberlândia
2006
MARCEL FAGUNDES SOUZA
SEGURANÇA EM SERVIDORES DE CORREIO ELETRÔNICO
Monografia apresentada à Faculdade de Ciências Aplicadas de Minas Gerais da União Educacional Minas Gerais (UNIMINAS), como parte das exigências do Título de Especialista em Segurança da Informação.
Orientador: Prof. Msc. Gilson Marques da Silva
Banca Examinadora:
Uberlândia, 13 de Maio de 2006.
________________________________________________ Prof. Msc. Gilson Marques da Silva - Orientador - UNIMINAS
________________________________________________
Prof. Msc. Alex Fabianne de Paulo - Faculdade Politécnica
________________________________________________ Prof. Dr. Mauro Hemerly Gazzani - UNIMINAS
Uberlândia
2006
AGRADECIMENTOS
Primeiramente a Deus, pela vida.
Aos meus pais, que me dão amor e carinho.
A UNIMINAS, pela realização de um sonho, cursar faculdade e em
seguida a especialização.
Aos amigos e professores, que direta ou indiretamente participaram da
realização deste sonho.
Eu poderia viver recluso numa casca de noz
e me considerar rei do espaço infinito...
(SHAKESPEARE, Hamlet, Ato 2, Cena 2).
RESUMO
O uso de sistema de correio eletrônico para comunicação eletrônica é muito
crescente o que significa que a informação trafegada é de extrema importância na
maioria dos casos. Assim, é necessário que esta informação trafegada se mantenha
sempre confiável, disponível e privada entre as partes interessadas. O analista de
segurança se preocupa em buscar a garantia de um bom nível de segurança, ou
seja, criar um ambiente que minimize a exposição das informações a pessoas não
autorizadas. Nesse sentido, este estudo faz a implementação de um servidor de e-
mail seguro para evitar o acesso não autorizado e envio de SPAM. No ambiente de
testes foi utilizado o sistema operacional Linux Red Hat, o mailscanner Amavisd-new
para verificação de anexos, o antispam SpamAssassin para a classificação das
mensagems como: SPAM ou ham, e por fim o antivírus Clamav para verificação de
vírus nos anexos. O acesso das mensagens foi utilizado o Dovecot com o protocolo
IMAP e o SASL para autenticação SMTP.
ABSTRACT
Using e-mail system through the electronic communication is growing a lot and it
means that the traffic of information is extremely important in the majority of the
cases; so it becomes necessary that the traffic information always keeps safe,
available and private for all intereted parties. In this case, the safety analyst makes
sure that getting a good safety level, i.,e., creates an environment that minimize the
information exposure to non authorized people. On this sense, this study makes the
implementation of a user safety e-mail avoiding the non authorized access and
sending the SPAM. On the environmental tests was used the operational system
Linux Red Hat, the mailscanner Amavisd- new checking the attached subjects, the
antispam Spam Assassin to the classification of the messages like: SPAM or ham,
and finally the Clamav antivirus checking the virus in the enclosed subjects. To the
access of the messages was utilized the Dovecot with the protocol IMAP and the
SASL to the authentication SMTP.
LISTA DE ILUSTRAÇÕES
Figura 1 - Exemplo de um agente MUA – Aplicativo Outlook Express da Microsoft .19 Figura 2 - Fase de autorização..................................................................................20 Figura 3 - Fase de transação ....................................................................................20 Figura 4 - Fase de atualização ..................................................................................21 Figura 5 - Modelo de uso do protocolo SMTP (POSTEL,1982).................................23 Figura 6 - Exemplo de envio de mensagem entre os servidores crepes.fr e
hamburger.edu...................................................................................................24 Figura 7 - Modelo de Sistema de Correio (GOVERNO FEDERAL, 2003).................25 Figura 8 - Estrutura Interna de um MTA....................................................................26 Figura 9 - Lata Presunto Picante - SPAM (Hormel Foods Corporation, 2005) ..........28 Figura 10 - Exemplo de um hoax ..............................................................................30 Figura 11 - Exemplo de um Phishing SCAM .............................................................31 Figura 12 - Exemplo de uma mensagem contendo vírus ..........................................32 Figura 13 - Exemplo de uma mensagem falsa ..........................................................33 Figura 14 - Mailbomber Kaboom ...............................................................................34 Figura 15 - Estatísticas de notificações de SPAM reportadas ao CERT.BR .............35 Figura 16 - Valores acumulados (SPAM, Proxy e Open Relay) ................................36 Figura 17 - Sintaxe do parâmetro header_checks.....................................................38 Figura 18 - Configuração do parâmetro header_checks ...........................................39 Figura 19 - Configuração das regras de filtragem no arquivo header_checks ..........39 Figura 20 - Sintaxe do parâmetro body_checks ........................................................40 Figura 21 - Configuração do parâmetro body_checks...............................................40 Figura 22 - Configuração das expressões regulares no arquivo body_checks .........40 Figura 23 - Configuração do parâmetro mydestination .............................................44 Figura 24 - Sintaxe do parâmetro mydestination.......................................................44 Figura 25 - Conteúdo do arquivo mydestination........................................................45 Figura 26 - Sintaxe do parâmetro mynetworks..........................................................45 Figura 27 - Configuração do parâmetro mynetworks ................................................45 Figura 28 - Sintaxe do parâmetro myhostname ........................................................47 Figura 29 - Configuração do parâmetro myhostname ...............................................47 Figura 30 - Sintaxe do parâmetro mydomain ............................................................47 Figura 31 - Configuração do parâmetro mydomain ...................................................47 Figura 32 - Sintaxe do parâmetro inet_interfaces......................................................48 Figura 33 - Configuração do parâmetro inet_interfaces ............................................48 Figura 34 - Arquivo de configuração Master.cf..........................................................50 Figura 35 - Criação do arquivo de log do freshsclam ................................................52 Figura 36 - Agendamento pelo Crontab ....................................................................52 Figura 37 - Configuração do Proxy............................................................................52 Figura 38 - Desativação do MTA Sendmail ...............................................................58 Figura 39 - Configuração do arquivo main.cf.............................................................59 Figura 40 - Configuração do arquivo main.cf - Continuação .....................................60 Figura 41 - Configuração do arquivo main.cf - Continuação .....................................61 Figura 42 - Configuração do arquivo master.cf .........................................................62 Figura 43 - Teste para verificação da disponibilidade do serviço SMTP ...................63 Figura 44 - Configuração do arquivo amavisd.conf ...................................................64 Figura 45 - Configuração do arquivo main.cf para integração com o Amavisd-new..65
Figura 46 - Configuração do arquivo master.cf para integração com o Amavisd-new...........................................................................................................................65
Figura 47 - Testando a porta 10024 do Amavisd-new...............................................66 Figura 48 - Configuração do arquivo clamav.conf .....................................................67 Figura 49 - Configuração do arquivo clamav.conf – Continuação.............................68 Figura 50 - Inicialização dos serviços........................................................................68 Figura 51 - Treinamento do SpamAssassin ..............................................................69 Figura 52 - Teste com a Mensagem Normal (DUCKLIN, 2003) ................................69 Figura 53 - Teste com a Mensagem EICAR (DUCKLIN, 2003).................................70 Figura 54 - Teste com a Mensagem com nível tag2 .................................................71 Figura 55 - Configuração do arquivo dovecot.conf....................................................72 Figura 56 - Configuração do SAS no arquivo smtpd.conf .........................................72 Figura 57 - Configuração do SASL no arquivo main.cf .............................................73 Figura 58 - Configuração das blacklist RHSBL e RBLs no main.cf ...........................74
LISTA DE TABELAS
Tabela 1 - Pacotes externos e dependências do Perl para Amavisd-new (SPENNEBERG, 2005) ......................................................................................63
LISTA DE ABREVIATURAS E SIGLAS
1. ARPA – Advanced Research Projects Agency
2. ARPANET – Advanced Research Projects Agency Network
3. BBN – Bolt Beranek and Newman
4. CERT BR – Centro de Estudos, Resposta e Tratamento de Incidentes de
Segurança no Brasil
5. CHROOT – Change root
6. CIDR – Classless Inter-Domain Routing
7. DARPA – Defense Advanced Research Projects Agency
8. DNS – Domain Name System
9. DMZ – DeMilitarized Zone
10. E-MAIL – Eletronic Mail
11. FQDN – Fully Qualified Domain Name
12. GNU – General Public License
13. HTML – Hypertext Markup Language
14. IBM – International Business Machines
15. IETF – Internet Engineering Task Force
16. IMAP4 – Internet Message Access Protocol version 4
17. IP – Internet Protocol
18. MAA – Mail Access Agent
19. MAPS – Massachusetts Alliance of Portuguese Speakers
20. MDA – Mail Delivery Agent
21. MTA – Mail Transfer Agent
22. MUA – Mail User Agent
23. MX – Mail eXchanger
24. NBSO – Network Information Center BR Security Office
25. PERL – Practical Extracting and Reporting Language
26. POP3 – Post Office Protocol version 3
27. RBL – Realtime Blackhole List
28. RFC – Request For Comments
29. RHSBL – Right-Hand-Side Backhole List
30. SASL – Simple Authentication and Security Layer
31. SPAM – SPiced hAM
32. SPF – Sender Policy Framework
33. TCP – Transport Control Protocol
34. TELNET – Terminal Emulator Link Over Network
35. UCE – Unsolicited Commercial E-mail
36. WWW – World Wide Web
SUMÁRIO
RESUMO................................................................................................................................................. 5
ABSTRACT............................................................................................................................................. 6
1 INTRODUÇÃO ................................................................................................................................... 14 1.1 O SURGIMENTO DA INTERNET ........................................................................................................ 14 1.2 OBJETIVOS DO TRABALHO.............................................................................................................. 15 1.3 JUSTIFICATIVA PARA A PESQUISA ................................................................................................... 15 1.4 ORGANIZAÇÃO DO TRABALHO ........................................................................................................ 17
2 SISTEMAS DE CORREIO ELETRÔNICO ........................................................................................ 18 2.1 MUA (MAIL USER AGENT) ............................................................................................................. 19
2.1.1 Protocolo POP3 (Post Office Protocol – Version 3) ............................................................ 20 2.1.2 Protocolo IMAP4 (Internet Message Access Protocol – Version 4) .................................... 21
2.2 MTA (MAIL TRANSFER AGENT) ...................................................................................................... 22 2.2.1 Protocolo SMTP (Simple Mail Transfer Protocol)................................................................ 22
2.3 MDA (MAIL DELIVERY AGENT) ....................................................................................................... 24 2.4 FUNCIONAMENTO DO CORREIO ELETRÔNICO .................................................................................. 24
3 TIPOS DE VULNERABILIDADES E TIPOS DE ATAQUES............................................................. 27 3.1 SPAM – SPICED HAM................................................................................................................... 27 3.2 CARACTERÍSTICAS E TIPOS DE SPAM............................................................................................. 29
3.2.1 Boatos - Hoaxes .................................................................................................................. 29 3.2.2 Fraudes e Golpes - SCAM .................................................................................................. 30 3.2.3 Vírus, worms e códigos maliciosos ..................................................................................... 31 3.2.4 Fake mail ............................................................................................................................. 32 3.2.5 Mail Bomber......................................................................................................................... 33
3.3 PROBLEMAS RELACIONADOS AO SPAM .......................................................................................... 34 4 FERRAMENTAS DE SEGURANÇA DA INFORMAÇÃO ................................................................. 37
4.1 MTA POSTFIX ............................................................................................................................... 37 4.1.1 Controle de mensagens comerciais não solicitadas ........................................................... 38
4.2 CONFIGURAÇÃO DO ARQUIVO MAIN.CF ............................................................................................ 43 4.2.1 Parâmetro - Mydestination .................................................................................................. 43 4.2.2 Parâmetro - Mynetworks ..................................................................................................... 45 4.2.3 Parâmetro - Myhostname .................................................................................................... 46 4.2.4 Parâmetro - Mydomain ........................................................................................................ 47 4.2.5 Parâmetro - inet_interfaces ................................................................................................. 48 4.2.6 Configuração do arquivo master.cf...................................................................................... 48
4.3 ANTIVÍRUS CLAMAV (CLAM ANTIVÍRUS).......................................................................................... 50 4.3.1 Configuração da atualização do banco de dados ............................................................... 51
4.4 ANTISPAM – SPAMASSASSIN .......................................................................................................... 52 4.4.1 Determinação da Pontuação pelo SpamAssassin .............................................................. 54
4.5 MAILSCANNER – AMAVISD-NEW (A MAIL VIRUS SCANNER – NEW) .................................................. 54 4.5.1 Determinação da Pontuação pelo Amavisd-new ................................................................ 55 4.5.2 Área de quarentena............................................................................................................. 56
5 IMPLEMENTAÇÃO DO SERVIDOR DE E-MAIL SEGURO ............................................................. 58 5.1 SISTEMA OPERACIONAL ................................................................................................................. 58 5.2 CONFIGURAÇÃO DO MTA POSTFIX ................................................................................................. 58 5.3 CONFIGURAÇÃO DO MAILSCANNER AMAVISD-NEW .......................................................................... 63 5.4 CONFIGURAÇÃO DO ANTIVÍRUS CLAMAV ........................................................................................ 66 5.5 FINALIZANDO A CONFIGURAÇÃO E TESTANDO .................................................................................. 69
5.6 CONFIGURAÇÃO DO DOVECOT IMAP ............................................................................................... 71 5.7 CONFIGURAÇÃO DO SASL (SIMPLE AUTHENTICATION AND SECURITY LAYER ).................................. 72 5.8 CONFIGURAÇÃO DAS BLACKLIST RHSBL E RBLS............................................................................ 73
6 CONCLUSÃO .................................................................................................................................... 75 6.1 TRABALHOS FUTUROS ................................................................................................................... 76
REFERÊNCIAS BIBLIOGRÁFICAS..................................................................................................... 77
14
1 INTRODUÇÃO
1.1 O Surgimento da Internet
A Internet surgiu na década de 60 com objetivo inicial de atender
necessidades militares do governo americano. A Internet é constituída por uma
série de redes interligadas através de backbones1. Em 1968 foi desenvolvido pela
ARPA (Advanced Research Projects Agency) o primeiro projeto de backbone. O
objetivo desse projeto era interligar as universidades e também as bases militares.
A DARPA (Defense Advanced Research Projects Agency) que deu lugar a ARPA
começou a desenvolver os protocolos TCP/IP (Transmission Control Protocol
/Internet Protocol) no ano de 1975 (TANENBAUM, 1997).
Na década de 80 a DARPA cedeu os direitos do código dos protocolos
TCP/IP à Universidade da Califórnia para que fosse distribuído junto com o sistema
operacional UNIX (Unics – Uniplexed Information and Computing System). A
DARPA solicitou que todos os computadores que estavam conectados a ARPANET
(Advanced Research Projects Agency Network) para que utilizassem os protocolos
TCP/IP. Com isso, esses protocolos se difundiram rapidamente, visto que não eram
aplicativos comerciais. Com o passar dos anos, a Internet vem se popularizando e
se tornando um dos meios de comunicação mais eficazes do planeta. Sua utilização
abrange desde fins pessoais e comerciais até fins não-legais (TANENBAUM, 1997).
De carona neste meio de tão fácil acesso e utilização, o serviço de
correio eletrônico é um dos serviços mais utilizados na Internet. O pré-requisito para
utilização do correio eletrônico é possuir um software que permite ao usuário
conectar-se ao seu servidor de correio e verificar as mensagens recebidas. Possuir
um endereço eletrônico que hoje em dia é uma grande vantagem, pois além de
possibilitar a simples troca de mensagens, ele permite a utilização de outros
serviços da Internet.
_____________ 1 O termo backbone (traduzindo para o português, espinha dorsal) designa o esquema de ligações centrais de um sistema mais amplo, tipicamente de elevado débito relativamente à periferia.
15
Atualmente, a segurança da informação é extremamente importante
porque à medida que aumenta o número de ataques e as descobertas de novas
vulnerabilidades vêm aumentando as falhas na segurança. O negócio de uma
empresa deve ser protegido por uma boa política de segurança calcada nos pilares
da segurança da informação: autenticidade, confidencialidade, disponibilidade,
integridade e irrevogabilidade.
1.2 Objetivos do Trabalho
Este trabalho tem como objetivo principal, implementar um servidor de
e-mail (eletronic mail) seguro, conforme as boas práticas de segurança para evitar
acesso não autorizado ou a utilização do servidor de e-mail para envio de
mensagens não solicitadas, isto é, SPAM (SPiced hAM). A finalidade deste trabalho
é apresentar um estudo sobre segurança em servidor de e-mail destacando a
importância do uso de configurações e procedimentos para melhoria na segurança
para prevenção de ameaças e contribuindo para a garantia da continuidade do
negócio da empresa.
Este trabalho tem como objetivos específicos:
• descrever o funcionamento de um servidor de e-mail;
• apontar as principais vulnerabilidades existentes, as principais
técnicas de ataques utilizadas;
• abordar as principais ferramentas de segurança da informação e por
fim a implementação de um servidor de e-mail seguro conforme as
boas práticas de segurança.
1.3 Justificativa para a Pesquisa
O serviço de correio eletrônico é um dos serviços de comunicação
eletrônica mais usados na Internet. Este serviço em geral provê pouco suporte à
segurança e privacidade, permitindo facilmente diversos tipos de fraudes e usos
indevidos e envio de SPAM e por alguns tipos de vermes. Os vermes utilizam-se do
pouco suporte na segurança para se multiplicar, causando inúmeros prejuízos.
16
Sendo assim, para garantir um nível ideal de segurança, o servidor
tem que estar bem configurado e atualizado, possibilitando menor exposição a
fraudes, uso indevido da informação, ataques bem sucedidos e a proliferação de
SPAM.
Estudos realizados por institutos de pesquisa demonstram o aumento
significativo do volume de mensagens indesejadas que trafegam na Internet, como
mostra a seguir:
Este estudo da empresa britânica MessageLabs revela que mais de 86% dos e-mails analisados em seus Datacenters distribuídos nos 4 continentes, em junho de 2004, são SPAM (MESSAGELABS ANTI-SPAM, 2004). Na sua configuração por padrão, muitos servidores SMTP vêm com o open relay, permitindo que eles sejam usados para enviar mensagens de e para qualquer rede ou domínio, independente dos endereços envolvidos serem da sua rede ou não. Estes servidores são amplamente explorados para envio de SPAM (NBSO, 2003). Este estudo mostra que grande parte dos SPAMs está ligada ao open relay, e que a solução proposta foi à configuração segura do relay amarrado a uma autenticação. Outro ponto descrito no estudo foi agregar uma ferramenta na infra-estrutura de rede, o antispam para o combater SPAMs, fechando o cerco no campo tecnológico (D'Ávila, 2005).
Diante disso, se a implementação de um servidor de correio eletrônico
não seguir as boas práticas de segurança este permitirá a exposição das
informações privadas à pessoas não autorizadas, isto é, não garantirá que a troca
de informações seja segura, confiável e disponível, restritas as partes interessadas.
E se a configuração do relay estiver aberta e sem autenticação este permitirá o
envio de SPAM por pessoas não autorizadas e contribuirá com a ploriferação de
vermes.
Os analistas de segurança conhecem bem a famosa lei de Murphy,
“Se alguma coisa pode dar errado, dará. E mais, dará errado da pior maneira, no
pior momento e de modo que cause o maior dano possível”. Mas não é bem assim,
as pesquisas mostram que as técnicas de invasão bem sucedidas estão cada vez
aumentando proporcionalmente com as vulnerabilidades. O analista de segurança
na verdade trabalha na prevenção e na correção destas vulnerabilidades.
Como garantir que o envio da mensagem seja entregue sem ser
violada ou alterada, que a mensagem seja a mesma que a pessoa enviou e não
permitindo negar que a enviou e que esta mensagem estará sempre disponível? A
investigação desta hipótese será feita através da implementação de um servidor de
17
e-mail, configurado de forma segura com objetivo de simular um ambiente real, para
dificultar a ação de um hacker ou de algum tipo de verme que tente aproveitar uma
brecha de segurança no serviço de e-mail.
1.4 Organização do Trabalho
Este trabalho está organizado da seguinte maneira: o capítulo 1 apresenta, de modo geral, os dados e informações que serão tratados no decorrer
da pesquisa, ressaltando os objetivos e resultados esperados com este trabalho. O
capítulo 2 descreve o sistema de correio de eletrônico, os componentes e o seu
funcionamento. No capítulo 3 as principais vulnerabilidades no servidor de e-mail,
como o Open Relay2, Open Proxy e o SPAM são apontados. Problemas
relacionados ao SPAM e alguns mecanismos para impedir o envio de e-mail SPAM.
Ainda no capítulo 3 são descritas as características do SPAM que utilizam recursos
fraudulentos para enganar o usuário. No capítulo 4 é apresentado um estudo das
principais ferramentas de segurança da informação usadas para minimizar a
proliferação de SPAM. No capítulo 5 é discutida a implementação do servidor de e-
mail seguro, conforme as boas práticas de segurança. No capítulo 6 a conclusão, os
resultados obtidos e as sugestões de trabalhos futuros pela pesquisa são
apresentados.
_____________ 2 O Open relay é um MTA que aceita conexões de qualquer rede e permitindo o envio de e-mails.
18
2 SISTEMAS DE CORREIO ELETRÔNICO
O correio eletrônico foi criado em 1971 por um engenheiro de
computação americano chamado Ray Tomlinson, que trabalhava na Bolt Beranek
and Newman (BBN), a empresa que fôra contratada pelo Departamento de Defesa
dos EUA para implantar a ARPANET (WINKMEDIA, 2005).
Nessa época, a rede tinha apenas 15 computadores interligados, e
Tomlinson desenvolvera um programa chamado SNDMSG que já continha os
princípios básicos do correio eletrônico: enviava um texto para uma caixa postal de
outra pessoa. Essa caixa postal era, na verdade, também um arquivo de texto e a
nova mensagem apenas acrescentavam um novo trecho ao texto ao arquivo que lá
se encontrava antes, sem a permissão de apagar ou sobrescrever.
Mas o SNDMSG funcionava apenas no âmbito local, e Tomlinson
decidiu adaptá-lo para funcionar entre diferentes nós da rede. Para distinguir os
endereços locais dos externos, o engenheiro decidiu que estes últimos teriam que
ter o símbolo @ entre o nome do usuário e o nome do computador onde se situava
a sua caixa postal.
O primeiro e-mail (eletronic mail) enviado na história foi um teste de
Tomlinson. Seu texto foi algo como QWERTYUIOP e a mensagem foi enviada por
Tomlinson para ele mesmo, através da ARPANET. Mas, fisicamente, os dois
computadores estavam lado a lado: eram duas máquinas da BBN que apenas
tinham conexão através da ARPANET para, assim, facilitar os testes. Após dois
anos, cerca de 75% do tráfego da ARPANET fazia a utilização do serviço de e-mail
(WINKMEDIA, 2005).
O sistema de correio eletrônico é o segundo serviço mais utilizado na
Internet, ficando atrás apenas das páginas Web (WWW - World Wide Web). O e-
mail atualmente é extremamente importante como forma de comunicação,
interligando e facilitando a comunicação de milhões de pessoas espalhadas pelo
mundo.
Os agentes são como componentes do correio e cada um têm funções
19
específicas que são descritas em detalhe a seguir (SCRIMGER, 2002):
2.1 MUA (Mail User Agent)
O agente usuário de correio é uma interface para acessar o MTA (Mail
Transfer Agent). Sua função é enviar ou receber as mensagens, assim como
interagir na compreensão do formato das mensagens colocando-a em modo
amigável. O MUA possui várias funções como enviar, excluir, recuperar responder,
encaminhar e também interage na verificação da ortografia e a gramática do texto, o
que facilita a manipulação da mensagem, conforme ilustrado na Figura 1.
O MUA usa o protocolo SMTP (Simple Mail Transfer Protocol) para
envio de mensagens, IMAP (Internet Message Access Protocol) para recuperação e
arquivamento de mensagens ou o POP (Post Office Protocol) para recuperação de
mensagens. Sendo este último com algumas características diferentes que serão
abordadas a seguir.
Figura 1 - Exemplo de um agente MUA – Aplicativo Outlook Express da Microsoft
20
2.1.1 Protocolo POP3 (Post Office Protocol – Version 3)
O protocolo POP3, referenciado na RFC (Request for coments)1939, é
um protocolo de correio simples e com poucas funcionalidades. O agente usuário
acessa os e-mails conectando ao servidor de correio na sessão TCP3 porta 110
onde estão armazenadas as suas mensagens. Esta conexão possui três fases:
autorização, transação e atualização. A autorização é feita através de uma senha e
em seguida solicita seus e-mails. As mensagens são transferidas para o
computador do usuário, podendo ser apagadas do servidor através de uma
solicitação do usuário (MYERS; ROSE, 1996).
A Figura 2 ilustra a fase de autorização. Para autorização foi utilizada
a sessão Telnet4 diretamente a um servidor de correio.
Figura 2 - Fase de autorização
Na fase de transação, o usuário pode configurar o POP3 para ler e
apagar, ou para ler e guardar, as mensagens. Para o comando ler e apagar o
usuário emite os seguintes comandos list, retr e dele. O exemplo da Figura 3
mostra que o usuário tem duas mensagens em sua caixa postal, onde C: significa
cliente e S: significa o servidor de correio.
Figura 3 - Fase de transação
_____________ 3 Transport Control Protocol é um protocolo da camada de transporte orientado a conexão. 4 Terminal Emulator Link Over Network é um programa que permite fazer conexão remota com outro computador.
telnet <nome do servidor> 110 +OK POP3 server ready user alice +OK pass hungry +OK user sucessfully logged on
C: list S: 1 498 S: 2 912 S: .
21
O agente usuário solicita para o servidor informar o tamanho de todas
as mensagens armazenadas. Em seguida as mensagens são recuperadas
utilizando o comando retr e para deletar as mensagens 1 e 2 foi utilizado o
comando dele. O comando quit finaliza a sessão com o servidor POP3 e remove as
mensagens 1 e 2 da caixa postal, conforme é mostrado na Figura 4.
Figura 4 - Fase de atualização
O problema no POP3 está no modo ler e apagar, o usuário pode se
deslocar e querer acessar em um outro computador. Este modo espalha as
mensagens por onde o usuário realizou o acesso. No modo ler e guardar o usuário
deixa as mensagens guardadas no servidor após lê-las, assim podendo ler
novamente as mensagens em máquinas diferentes.
2.1.2 Protocolo IMAP4 (Internet Message Access Protocol – Version 4)
O protocolo IMAP, definido na RFC 2060, foi criado para resolver as
deficiências do protocolo POP3. O IMAP permite acessar mensagens armazenadas
em um servidor como se estivessem armazenadas em um computador local. Esta
versatibilidade permite o usuário acessar as mesmas mensagens em diversos
computadores ao mesmo tempo. O protocolo IMAP trabalha em uma arquitetura
cliente/servidor usando a porta TCP 143, podendo estar em um dos seguintes
estados (CRISPIN, 1996):
• Estado não-autenticado: É o estado onde o usuário fornecerá o
usuário e a senha para liberação dos comandos.
C: retr S: (Teste de Envio 1 ... S: .... Teste de Envio 1) C: dele 1 C: retr 2 S: (Teste de Envio 2 ... S: .... Teste de Envio 2) C: dele 2 C: quit S: +OK POP3 server signing off
22
• Estado autenticado: É o estado onde o usuário poderá selecionar a
pasta para utilizar os comandos.
• Estado selecionado: É o estado onde o usuário poderá utilizar os
comandos que afetam as mensagens (recuperar, mover, apagar,
recuperar parte de uma mensagem).
• Estado de logout: É usado para encerrar a sessão.
Na época que o protocolo IMAP foi concebido, os projetistas não se
preocupavam com a segurança das mensagens. Qualquer troca de mensagem
realizada entre o cliente e servidor não utilizava criptografia, o que permitirá qualquer
um capturar o tráfego (NORTHCUTT; NOVAK; MCLACHLAN, 2001).
2.2 MTA (Mail Transfer Agent)
É um agente de transferência de mensagens que tem funções de
encaminhamento e de transferência de mensagens entre um servidor de correio de
origem a um servidor de correio de destino. O encaminhamento e transferência de
mensagens é feito pelo protocolo SMTP na porta 25.
2.2.1 Protocolo SMTP (Simple Mail Transfer Protocol)
O protocolo SMTP é usado para enviar e-mail do servidor de correio
de origem para o servidor de correio de destino final, ou seja, o cliente SMTP
conecta com o servidor SMTP e instrui o mesmo usando comandos para que o e-
mail seja enviado ao destinatário final.
A Figura 5 ilustra o fluxo de funcionamento do protocolo SMTP.
• Inicialmente é estabelecida a conexão entre SMTP-Emissor e o
SMTP-Receptor, onde o SMTP-Receptor pode ser o destino final ou
somente um encaminhador da mensagem;
• O SMTP-Emissor envia a identificação do remetente da mensagem
e em seguida SMTP-Receptor envia como resposta o OK;
• Identifica-se o destinatário da mensagem e o SMTP-Receptor
verifica se este existe;
23
• E finalmente é identificado o destinatário, o SMTP-Emissor começa
a transmissão da mensagem.
SMTPReceptor
SMTPEmissor
Comandos/respostase e-mails
Figura 5 - Modelo de uso do protocolo SMTP (POSTEL,1982)
A Figura 6 mostra um exemplo de envio de uma mensagem, “Do you
like ketchup? How about pickles?”, do servidor de correio crepes.fr para o servidor
hamburger.edu (KUROSE; ROSS, 2003):
• O servidor crepes.fr envia comando HELO para estabelecer uma
sessão TCP na porta 25 com o servidor hamburger.edu;
• Em seguida o servidor crepes.fr envia o comando MAIL para o
servidor hamburger.edu para iniciar a transação, e a seguir envia o
comando DATA para informar ao servidor que a mensagem vem em
seguida;
• O servidor hamburger.edu reconhece a mensagem enviando o
comando OK;
• A mensagem é armazenada no servidor SMTP até que seja
transferida para o servidor hamburger.edu.
24
Figura 6 - Exemplo de envio de mensagem entre os servidores crepes.fr e hamburger.edu
2.3 MDA (Mail Delivery Agent)
É o agente de entrega de correio, este agente recebe o e-mail do
agente MTA e o deposita na caixa de correio do usuário.
2.4 Funcionamento do Correio Eletrônico
A Figura 7 ilustra o caminho percorrido para a entrega de uma simples
mensagem, ou seja, o e-mail. A mensagem é criada pelo MUA. Em seguida a
mensagem é encaminhada para um servidor de correio MTA, onde é consultada a
informação em um servidor DNS5 (Domain Name System) para verificar se a
mensagem é local ou se é de outro servidor, caso a mensagem seja de outro
servidor a mensagem é enviada para o MTA de destino.
_____________ 5 DNS é a sigla para Domain Name System ou Sistema de Nomes de Domínios. É uma base de dados hierárquica, distribuída
para a resolução de nomes de domínios em endereços IP e vice-versa.
S: 220 hamburger.edu C: HELO crepes.fr S: 250 Hello crepes.fr, pleased to meet you C: MAIL FROM: [email protected] S: 250 [email protected] ... Sender ok C: RCPT TO: [email protected] S: 250 [email protected] ... Recipient ok C: DATA S: 354 Enter mail, end with “.” on a line by itself C: Do you like ketchup? C: How about pickles? C: . S: 250 Message accepted for delivery C: QUIT S: 221 hamburger.edu closing connection
25
Figura 7 - Modelo de Sistema de Correio (GOVERNO FEDERAL, 2003)
O transporte das mensagens entre os MTAs é feito pelo protocolo
SMTP, o que permite conexões de outros servidores de correio ou MUAs. Se a
mensagem for para entrega local, a correspondência é passada para um MDA que
armazena a correspondência da caixa de correio do usuário. O MUA busca a
mensagem disponível no MTA de destino e exibindo-a em modo amigável. A busca
e entrega das mensagens da caixa de correio é feito pelo MAA (Agentes de Acesso
ao Correio), este termo é usado para representar o modelo tradicional MTA, MDA,
MUA. O MUA conecta a um MAA utilizando um protocolo de correio IMAP ou POP,
conforme mostra a Figura 8.
MUA 1 MUA 2
SMTP
SMTP
MTA 2MTA 1
Web mail
POP
IMAP
26
MTAMTAMTA
SMTP
SMTP
POP
IMAP
IMAP
Acesso Direto ao MUA
Permite conexão de MUAs ou de outros MTAs
Entrega a mensagem a outros MTAs
MDAMDA MAA
Caixa de CorreioCaixa de Correio
Figura 8 - Estrutura Interna de um MTA
27
3 TIPOS DE VULNERABILIDADES E TIPOS DE ATAQUES
A insegurança de alguns serviços que, se mal configurados, podem
permitir que usuários não autorizados utilizem destes recursos indevidamente. A
configuração incorreta destes serviços pode causar vários problemas indesejáveis.
O exemplo é o proxy e o relay, se mal configurados, podem permitir que usuários
externos abusem dos recursos da rede, ainda que isso não implique na ocorrência
de uma invasão. Dois destes serviços são o e-mail e os proxies de Web (NBSO,
2003).
A configuração incorreta destes serviços pode causar vários efeitos
indesejáveis. Um deles é que recursos computacionais da organização, link
Internet, CPU, discos e memória dos servidores, são consumidos por terceiros sem
que eles paguem por esse uso. Em muitos casos, esses recursos são exauridos de
forma que usuários legítimos não possam utilizar o serviço. Além disso, servidores
mal configurados são muitas vezes usados para disseminar conteúdo ilegal.
3.1 SPAM – SPiced hAM
O termo “SPAM” surgiu da marca de um tipo de presunto picante
enlatado da Hormel Foods Corporation, conforme mostra a Figura 9, uma empresa
americana que vende o produto deste 1937. A palavra foi utilizada em um quadro
do grupo de humoristas ingleses chamado Monty Phyton para especificar o envio de
e-mails a uma grande quantidade de pessoas de uma vez e é conhecido também
pela sigla inglesa UCE (Unsolicited Commercial Email), ou Mensagem Comercial
Não-Solicitada (INFOGUERRA, 2003).
28
Figura 9 - Lata Presunto Picante - SPAM (Hormel Foods Corporation, 2005)
O primeiro e-mail SPAM enviado de que se tem notícia foi um anúncio
da DEC, fabricante de computadores, que falava sobre a nova máquina DEC-20, no
ano de 1978. A mensagem, que foi enviada na ARPANET6, dava detalhes sobre o
novo produto e convidava as pessoas para apresentações na Califórnia o que gerou
polêmica na rede por violar as regras de uso da ARPANET (INFOGUERRA, 2003).
A maioria dos e-mails de fraudes são enviados no formato HTML
(Hypertext Markup Language), o que permite adicionar recursos visuais como
imagens, cores e fontes que ajudam a chamar a atenção e dissimular o conteúdo
enganoso.
Às vezes a mensagem inclui um link para uma home page falsa que
não tem nenhuma relação com o remetente. Além disso, quase sempre o link
aponta para um arquivo executável, normalmente com as seguintes extensões:
*.exe, *.com, *.scr, *.cpl, *.bat, *.pif, entre outras, ou ainda o arquivo pode estar
compactado *.zip contendo arquivo executável. O recomendável é que sempre se
verifique o endereço de destino de um link antes de clicar no anexo.
_____________ 6 Advanced Research Projects Agency Network, rede de pesquisa avançada do Departamento de Defesa dos EUA, que deu
origem à Internet.
29
3.2 Características e tipos de SPAM
O analista de segurança tem que se preocupar com a prevenção do
Open Relay, para não permitir que pessoas de outras redes sejam autenticadas no
servidor de e-mail. Esta vulnerabilidade é muito usada pelos Spammers, Vírus e
Worms para envio de e-mails SPAM.
3.2.1 Boatos - Hoaxes
Os boatos, também chamados de hoaxes, são e-mails que possuem
conteúdos falsos e tem objetivo de iludir ou alarmar, para que as pessoas
divulguem para o maior número de pessoas (HAMBRIDGE, 2005).
A história deste pseudovírus da Figura 10 conta que o vírus alojaria
num arquivo do Windows para destruir as informações do computador no dia vinte e
cinco. O e-mail passa instruções para deletar o pseudovírus. Este boato surgiu em
2001 no Brasil, e logo foi divulgado pelo mundo, onde deixou muita gente
preocupada.
A verdade é que o arquivo sulfnbk.exe não é um vírus, ele é um
programa do sistema operacional Windows que possibilita a manipulação de
arquivos com nomes extensos, isto é, arquivos cujos nomes tenham acima de oito
caracteres.
Para verificar se o e-mail é um boato, existem sites como o “caça
boatos”, http://HoaxBusters.ciac.org/, onde se encontram listas contendo os boatos
que estão circulando pela Internet e seus respectivos conteúdos (NBSO, 2003).
30
Figura 10 - Exemplo de um hoax
3.2.2 Fraudes e Golpes - SCAM
O SCAM7 é um tipo de SPAM que utiliza recursos fraudulentos usados
para ludibriar o destinatário com objetivo de ganho financeiro. Este tipo de fraude
tem sido denominado SCAM ou phishing scam, a palavra inglesa fishing que
significa pescaria, o phishing é o ato de enviar um e-mail a alguém, alegando
falsamente ser uma entidade de uma empresa ou organização para tenta fazer que
a vítima entregue informações onde serão utilizadas para fins escusos, como por
exemplo, o roubo de informações pessoais. O e-mail fraudulento tem um link que
direciona o usuário a visitar uma página Internet onde será solicitado a atualizar as
informações pessoais: senhas, cartões de crédito, contas de banco e outros dados
que uma organização legítima possui, conforme é ilustrado na Figura 11.
_____________ 7 SCAM é um tipo de SPAM que utilizam recursos fraudulentos usados para ludibriarem o destinatário com objetivo de ganho
financeiro.
Procure em seu computador pelo arquivo: sulfnbk.exe
Vá ao iniciar, procurar (ou localizar) e localize este arquivo edelete-o imediatamente (caso seja encontrado, ele se aloja no c:\windows\command). Após isto esvazie a lixeira !
Trata-se de um vírus que vem através de e-mails sem você perceber e pretende destruir seu computador no dia 25.
Este alerta foi passado pelo setor de computação da FEG/UNESP. Elimine o tal programa, mas de qualquer forma, seria bom no dia 24 antes de desligar o micro, certificar-se de que ele não entrou novamente.
31
Figura 11 - Exemplo de um Phishing SCAM
Pela facilidade de se forjar uma página da web para que fique
semelhante com a página original. Muitos usuários são vítimas por este tipo de
ataque. Ao enviar os e-mails para um número grande de usuários, o atacante ou
neste caso, o phisher, acaba conseguindo um bom número de informações que
servem aos seus propósitos.
3.2.3 Vírus, worms e códigos maliciosos
O fato é que certos vírus e worms8 se propagam por e-mail e para
convencer o usuário a executar o arquivo anexo, ou seja, o código malicioso. Os
recursos usados são semelhantes aos usados pelos Spammers: estimular a
curiosidade. Um exemplo comum é mostrado na Figura 12, o e-mail com anexo ou
um link de acesso a uma URL infectado com vírus e também com uma estória ou
frase qualquer para tentar estimular a curiosidade do usuário para abri-lo.
_____________ 8 Também conhecido como verme. É semelhante ao vírus, no caso do Worm não depende de intervenção para ser ativado.
32
Figura 12 - Exemplo de uma mensagem contendo vírus
3.2.4 Fake mail
O Fake mail significa e-mail falso, é uma técnica para envio de
mensagens falsas, como mostra a Figura 13. A pessoa conecta-se a um servidor
SMTP para forjar um e-mail fingindo-se passar por uma pessoa importante e
estratégica na empresa. Esta técnica pode ser bastante efetiva, pois uma vez que o
remetente pode enviar um e-mail onde ele consegue forjar tanto um e-mail legítimo
como também um e-mail que não existe, por isso, desta forma de ataque atinge a
maioria dos usuários inexperientes.
Por que não responde. Há tempo observo voce, sei que meconhece e nunca me manifestei, porque fico com um pouco dereceio.
Refiz a hospedagem da mensagem e da foto. Coloquei novamente na UOL com a senha 102030a.
Espero que goste, mas por favor mantenha discrição.Mas caso não goste, esqueça tudo isso.
Adoro você, tchau ....
Arquivo em anexo(s) fotos.jpg (179KB)
33
Figura 13 - Exemplo de uma mensagem falsa
3.2.5 Mail Bomber
O Mail bomber é um ataque que envia uma grande quantidade de e-
mail para inundar a caixa de correio do alvo. Este ataque exige um servidor SMTP
com open relay para ser utilizado para o envio do mail bomber. Um dos softwares
que pode ser usado para esse ataque é o Kaboom, mostrado na Figura 14. O
atacante escolhe a sua vítima e um servidor SMTP vulnerável para enviar uma
grande quantidade de e-mails. Este ataque inunda a caixa de correio da vítima e
pode causar a parada um servidor de e-mail caso a caixa de correio não possuir
uma cota.
telnet <nome do servidor> 25
helo <endereço do domínio> <enter>a resposta deve ser a seguinte250 OK
mail from: <endereço falso do remetente> <enter>a resposta deve ser a seguinte250 OK – mail from < o endereço falso de correio >
rcpt to: <endereço da vítima> <enter>a resposta deve ser a seguinte250 OK – Recipient <endereço da vítima>
data <enter>a resposta deve ser a seguinte354 Send data. Finalizar com CRTF. CRLF
To: < endereço da vítima > <enter>From: <endereço falso do remetente> <enter>Suject: <Assunto Troca de Senha root – “Mensagem Falsa”> <enter><Solicitamos a troca da senha root para a senha padrão. Atenciosamente, Administrador de Sistema> <enter> <enter> . <enter>a resposta deve ser a seguinte250 OKquit <enter>
34
Figura 14 - Mailbomber Kaboom
3.3 Problemas relacionados ao SPAM
Muitos servidores vêm com o open relay na configuração padrão, o
que permite que seja utilizado para enviar mensagens a qualquer endereço
desejado, e também pode ser usado para envio de SPAM. Outra motivação do open
relay, o Spammer pode ter o anonimato que torna difícil às chances de punição por
este abuso.
Em muitos casos é possível fechar o relay mesmo quando a rede
possui roaming users (usuários ambulantes), usando mecanismos como POP-
before-SMTP e SMTP AUTH. Os mecanismos POP-before-SMTP e SMTP AUTH
exigem que sejam feitas autenticações no servidor de e-mail para evitar o uso não
autorizado do servidor, mas permitindo que clientes realizem o envio de mensagens
a partir de servidores remotos. Estas implementações exigem dos clientes
autenticar-se no servidor POP ou IMAP antes de realizar o envio de mensagens,
comprovando que ele está na máquina e que deseja realizar o envio.
Outra vulnerabilidade que pode ser utilizada se mal configurada é o
35
Proxy de Web, também pode ser utilizada se não forem tomadas devidas
precauções. Um proxy mal configurado pode ser usado por pessoas não
autorizadas para acessar os recursos anonimamente para envio de mensagens
falsas ou fraudulentas ou até mesmo SPAM.
A configuração recomendada no Proxy Web é que somente permite o
acesso aos endereços IPs (Internet Protocol) dos usuários autorizados que
pertence à rede.
A diferença entre os mecanismos open relay e o open proxy é que o
open relay está presente somente em servidores de e-mail, normalmente devido a
uma má configuração por falta de conhecimento do analista de segurança.
Realizar a prevenção do servidor com o open relay e do open proxy é
extremamente importante. Os Spammers podem utilizar o servidor de e-mail para o
envio de e-mails SPAM e com pouco tempo o domínio poderá ser cadastrado em
listas negras. O problema é preocupante, pois o número de e-mails SPAM vem
crescendo a cada ano que passa. A Figura 15 representa a quantidade de
vulnerabilidades reportadas de 2003 até março de 2006 que comprova este fato.
Figura 15 - Estatísticas de notificações de SPAM reportadas ao CERT.BR
A Figura 16 mostra a evolução das notificações de SPAM reportadas
ao CERT.BR (Centro de Estudos, Resposta e Tratamento de Incidentes de
36
Segurança no Brasil) pelos principais provedores de serviços de Internet.
Figura 16 - Valores acumulados (SPAM, Proxy e Open Relay)
A RFC 2142 define uma série de e-mails padrão que devem existir em
todas as redes e que podem ser usados para contatar aos analistas responsáveis.
Dentre os endereços padrão, existem dois que estão relacionados com segurança:
abuse e security. O endereço abuse é usado para reportar abusos de recursos na
rede. O endereço security, por sua vez, é utilizado para comunicar incidentes e
alertar sobre problemas de segurança (CROCKER, 1997).
Para todo e qualquer incidente relacionado ao SPAM, deve ser feita
uma reclamação aos responsáveis da rede e em seguida encaminhada à entidade
responsável o NBSO (Network Information Center BR Security Office). Com isso o
NBSO manterá dados estatísticos de incidência de SPAM e apontar às redes com
servidores que não estão configuradas adequadamente (NBSO, 2003).
37
4 FERRAMENTAS DE SEGURANÇA DA INFORMAÇÃO
Os pilares da segurança da informação, confidencialidade, integridade
e disponibilidade representam as principais propriedades que garantem a
segurança de um sistema de informação. O não-repúdio também se faz necessário,
principalmente com o avançar do comércio eletrônico e o crescimento das
transações comerciais através de redes eletrônicas públicas ou privadas.
4.1 MTA Postfix
O MTA Postfix foi escrito e atualizado por Wietse Zweitze Venema e
atualmente distribuído com licença GNU (General Public License). Inicialmente, o
Postfix era conhecido como VMailer e foi lançado no final de 1998 pela IBM
(International Business Machines) com o nome de IBM Secure Mailer. A partir de
então, Venema e a IBM liberaram o código, onde o VMailer assumiu o nome de
Postfix como é conhecido até hoje (IBM; VENEMA, 1998).
A proposta do Postfix era ser um servidor de e-mail, com uma coleção
de pequenos programas, relativamente simples e rápidos, que trabalhariam juntos
para fazer o trabalho que o Sendmail já fazia. Diferentemente do Sendmail que é
um grande programa monolítico, com uma linguagem de configuração ou
programação bastante complexa (IBM; VENEMA, 1998).
O Postfix foi criado para ser uma alternativa viável ao Sendmail. Assim
o Postfix foi desenvolvido para ser semelhante ao MTA Sendmail, mas internamente
é completamente diferente, mas sendo compatível com o Sendmail para facilitar a
migração de usuários.
A construção do Postfix foi com dispositivos que ajudam garantir a
segurança. O conceito de jaula foi implementado, ou seja, permite que os daemons
sejam configurados para serem enjaulados no chroot (change root), para que estes
daemons executem com privilégios fixo, obtendo maior proteção do sistema contra
invasores. Outro dispositivo de segurança é o Controle de UCE, que faz a restrição
dos clientes não autorizados fazer o relay. O Postfix implementa recursos de
controle de e-mails SPAM tais como: listas negras, procuras na RBL (Realtime
38
Blackhole List), lookups DNS de remetentes/HELO, e uma filtragem de conteúdo, o
que serão detalhadas posteriormente.
4.1.1 Controle de mensagens comerciais não solicitadas
O Postfix fornece grande flexibilidade na configuração de parâmetros
que podem ajudar a diminuir a quantidade de recebimento de mensagens
comerciais não solicitadas. Assim, o Postfix pode ser configurado para aceitar
somente mensagens originadas ou com o destino da rede ou domínio que são
foram previamente liberados. Dessa forma, evita que o relay fique aberto para que
sejam acessados por pessoas não autorizadas.
Algumas das restrições podem ser implementadas em um MTA Postfix
no auxílio no combate ao SPAM que estão descritas nas subseções a seguir.
4.1.1.1 Filtragem de cabeçalhos
Esta opção de filtragem permite recusar mensagens baseando-se no
conteúdo dos campos do cabeçalho da mensagem: From, Address, Location, Date,
Subject. Entretanto, esta regra verifica a presença de uma string específica em
qualquer um dos campos do cabeçalho da mensagem.
Para configurar esta opção de filtragem, insira o parâmetro
header_checks no arquivo de configuração o main.cf, onde este arquivo será
abordado com mais detalhes.
A sintaxe para esse parâmetro é a seguinte, conforme mostra a Figura
17.
Figura 17 - Sintaxe do parâmetro header_checks
Onde o parâmetro [mapa] é o tipo de mapa de lookup que utiliza o
arquivo [arquivo_de_regras], contendo as regras de filtragem.
header_checks = [mapa]:[arquivo_de_regras]
39
O Postfix suporta vários mapas de lookup. Os mais utilizados para
filtragem de conteúdo usando o parâmetro header_checks são os mapas regexp e
o mapa pcre. A verificação de quais mapas o Postfix suporta, é feito pelo comando:
postconf –m.
O mapa pcre suporta expressões regulares na sintaxe do Perl
(Practical Extracting and Reporting Languaje)9 para criação de suas regras de
filtragem. Agora o mapa regexp oferece suporte ao uso de expressões regulares
comuns. As regras de filtragem ficam no arquivo /etc/postfix/header_checks. O
exemplo desta regra fica assim, como é mostrado na Figura 18:
Figura 18 - Configuração do parâmetro header_checks
Após definir o parâmetro no arquivo main.cf, é preciso criar as regras
de filtragem no arquivo especificado pelo parâmetro header_checks.
Os parâmetros do arquivo header_checks ficaram conforme a Figura
19.
Figura 19 - Configuração das regras de filtragem no arquivo header_checks
4.1.1.2 Filtragem do corpo de mensagens
Esta outra opção de filtragem permite recusar mensagens baseando-se
no conteúdo dos campos do corpo da mensagem. Os mesmos mapas de lookup e
_____________ 9 Perl é uma linguagem de programação muito prática para extrair informação de arquivos de texto e gerar informes a partir do conteúdo dos arquivos.
header_checks = regexp:/etc/postfix/header_checks
/^From:.*spammer@spammer\.com\.br/ REJECT
/^Subject:.*Ganhe Dinheiro fácil/ REJECT
/^Subject: Great News for All Music Fans/ REJECT
/^Subject: MORTGAGE BAD CREDIT/ REJECT
40
as expressões regulares podem ser usados. A sintaxe para esse parâmetro é
mostrada na Figura 20.
Figura 20 - Sintaxe do parâmetro body_checks
O exemplo desta regra fica conforme é mostrada na Figura 21.
Figura 21 - Configuração do parâmetro body_checks
Os parâmetros do arquivo body_checks ficaram como na Figura 22.
Figura 22 - Configuração das expressões regulares no arquivo body_checks
4.1.2.3 Filtragem por detecção de clientes MTAs que violam as regras de negociação do protocolo SMTP
Os softwares de mailing normalmente não cumprem algumas regras de
negociação do protocolo SMTP. Os Spammers utilizam estes recursos para
agilizarem o processo de entrega de SPAM. Essas violações de especificações do
protocolo SMTP podem ser usadas na detecção e combate a SPAM. Alguns
body_checks = [mapa]:[arquivo_de_regras]
body_checks = regexp:/etc/postfix/body_checks
/^Olá como está=3F$/ REJECT
/(usa\.net|hotmail\.com|yahoo\.com)\?subject=remove/ REJECT
/^[ ]*name=.*\.(exe|bat|jar|asp|aspx|dll|eml|vbs)/ REJECT
/.*www\.removeyou\.com.*/ REJECT
/.*waterforge\.com.*/ REJECT
/.*capitalwave\.com\?subject=Please*/ REJECT
/\.virtmundo\.com/ REJECT
/trabalhe em casa.*renda extra/ REJECT
/GUARANTIDO!/ REJECT
41
exemplos de macros estão listados a seguir:
• check_helo_access, check_client_access, check_recipient_
access e check_sender_access: Estas macros verificam a
respectiva informação (identificação de máquina ou HELO, endereço
IP ou hostname, destinatários e remetentes) em uma fonte de
dados/mapeamento;
• reject_unknown_sender_domain e reject_unknown_recipient _domain: As macros verificam se o domínio do remetente ou
destinatário existem, ou seja, se possuem um registro DNS ou MX
(Mail eXchanger) válido;
• reject_non_fqdn_sender/recipient: Impede o uso de abreviações
para remetentes e destinatários. O servidor por padrão adiciona o
hostname quando o domínio do remetente ou destinatário está em
branco;
• reject_unknown_client: Impede que clientes sem o DNS reverso
acessem o servidor;
• reject_invalid_hostname, reject_non_fqdn_hostname e reject _unknown_hostname: Obriga o uso de comandos HELO/EHLO
válidos no início da sessão SMTP. Estas macros mostram-se bastante
úteis no combate ao SPAM, uma vez que a maioria dos Spammers
usa hostnames falsos ou nao-completamente-qualificados non_fqdn
no comando HELO. A macro reject_unknown_hostname causa mais
prejuízo do que benefício, pois ela procura o endereço fornecido no
DNS, onde existe uma grande quantidade usando nomes que não
podem ser resolvidos pelo DNS.
4.1.2.4 Requisição de endereços de envelope no estilo estritamente compatível com a RFC 821.
Esta filtragem permite detectar ou obrigar o uso de sintaxes
especificadas na RFC 821. As configurações possíveis no arquivo main.cf são:
• strict_rfc821_envelopes = yes: Obriga que o endereço informado
42
na sessão seja um endereço de e-mail válido entre os caracteres
menor e maior <>, respectivamente. Por exemplo, opções inválidas:
MAIL FROM: [email protected] , MAIL FROM:
<[email protected]>; Apenas a forma MAIL FROM:
<[email protected]> é válida;
• smtpd_helo_required = yes: Exige que se passe um comando
HELO/EHLO antes de passar os dados da sessão.
4.1.2.5 RBLs (Realtime Blackhole List)
As RBLs foram criadas em 1997 por Paul Vixie no projeto MAPS
(Massachusetts Alliance of Portuguese Speakers). Na época este era o único
serviço de bloqueio de SPAM. As RBLs são serviços de bloqueio de SPAM
baseados em listas negras de DNS. Estes serviços são configurados nos servidores
de e-mail para utilização de consulta a blacklists (lista negra) rejeitando as
mensagens caso ela faça parte da lista negra. Este serviço faz publicação de listas
contendo endereços IPs de servidores que são utilizados para a propagação de
SPAM e as disponibilizam para consultas, (MAPS – MAIL ABUSE PREVENTION
SYSTEM, 2004).
Para usar RBLs no Postfix, basta adicionar as macros
(reject_rbl_client endereço do dominio.da.rbl) na configuração
smtpd_client_restrictions.
4.1.2.6 RHSBL (Right-Hand-Side Blackhole List)
A RHSBL é uma evolução as RBLs, que consiste na consulta de
domínios e para obter o hostname do servidor ao invés de IPs (MAPS – MAIL
ABUSE PREVENTION SYSTEM, 2004).
Para configuração no Postfix basta acrescentar a macro
(reject_rhsbl_sender endereço do dominio.da.rhsbl) e a macro (reject_rhsbl_client
endereço do dominio.da.rhsbl) nas configurações de smtpd_sender_restrictions e
smtpd_client_restrictions respectivamente.
43
4.1.2.7 SPF (Sender Policy Framework)
O SPF foi iniciado por Meng Weng Wong em julho de 2004, com o
propósito de ser um padrão da IETF (Internet Engineering Task Force) (KNIGHT,
2005). O SPF faz a validação de fontes legítimas de e-mails de um determinado
domínio. Esta validação é feita através de entradas DNS que definem um protocolo
no qual os proprietários de domínios fazem a autorização dos hosts que usem o
nome do domínio na saudação SMTP, MAIL FROM ou o HELO.
O controle do SPAM do SPF se baseia no domínio do remetente da
mensagem, e isso é uma vantagem porque a reputação do nome de domínio é mais
confiável que a reputação do endereço IP ou host. O SPF torna mais difícil para os
Spammers enviarem SPAM, porque geralmente os Spammers forjam o endereço de
e-mail do remetente para enviar SPAM. Agora no SPF isso não é possível, pois os
SPAM vão ser barrados pelos servidores de e-mail que usarem o serviço.
4.2 Configuração do arquivo main.cf
O principal arquivo de configuração do Postfix é o main.cf, onde está
localizado no diretório /etc/postfix. É neste arquivo onde a maior parte das
configurações dos parâmetros é feita. Após alterar os parâmetros, o Postfix precisa
reler o arquivo de configuração main.cf para que sejam aplicadas as novas
configurações. A sintaxe do comando é postfix reload. Este comando evita que o
servidor seja reiniciado, ou seja, evita que os usuários percam o acesso ao servidor
de e-mail momentaneamente.
4.2.1 Parâmetro - Mydestination
Quando uma mensagem chega na fila de mensagens de um MTA. O
Postfix verifica se a mensagem deve ser entregue no servidor local ou deve ser
encaminhada para outro MTA. As mensagens são verificadas pelo parâmetro após
o símbolo da arroba, o que significa a qual domínio que a mensagem pertence. Esta
verificação é feita consultando o servidor DNS, através da informação recebida pelo
44
registro do tipo MX, do MTA responsável pelo domínio da mensagem. De posse
desta informação, o MTA encaminha a mensagem para o outro MTA responsável
por este domínio.
O parâmetro mydestination indica os domínios o MTA e o destino
final, ou seja, para quais domínios irão receber as mensagens. Quando uma
mensagem entra na fila de mensagens do Postfix, o parâmetro mydestination é
verificado para saber se o domínio de destino da mensagem está configurado para
aceitar as mensagens.
Caso o domínio esteja listado no parâmetro mydestination, a
mensagem é repassada para o transporte local do Postfix, que por sua vez se
encarrega de entregar a mensagem na caixa de mensagens do usuário. Este
repasse é feito pelo parâmetro local_transport que está configurado no arquivo
main.cf. Se o domínio não estiver listado no parâmetro mydestination, uma outra
consulta ao servidor DNS é feita para verificar o MTA responsável pelo domínio e
em seguida a mensagem é repassada para o MTA de destino.
O uso do parâmetro mydestination é vantajoso, pois neste caso, não
seria necessária a consulta ao servidor DNS para descobrir o MTA responsável pelo
domínio, tornando a entrega da mensagem mais rápida.
A sintaxe do parâmetro mydestination é mostrada na Figura 23.
Figura 23 - Configuração do parâmetro mydestination
Como alternativa, pode ser criado um arquivo contendo os domínios
desejados, como mostra a Figura 24.
Figura 24 - Sintaxe do parâmetro mydestination
O arquivo /etc/postfix/mydestination tem o seguinte conteúdo,
conforme mostra a Figura 25.
mydestination = dominio1.com.br, dominio2.com.br, dominio3, com.br
mydestination = /etc/postfix/mydestination
45
Figura 25 - Conteúdo do arquivo mydestination
4.2.2 Parâmetro - Mynetworks
Este parâmetro, por padrão, vem com o open relay, ou seja, recebe e
aceita em sua fila mensagens enviadas para qualquer destino, seja ele local ou não.
O que não é recomendável no ponto de vista de segurança.
Caso o ambiente possua várias redes e o servidor de e-mail possua
várias interfaces de rede, neste exemplo serão compreendidas três interfaces, uma
interface de rede na rede interna A, uma interface de rede interna B e outra privada
do tipo DMZ (DeMilitarized Zone)10, o Postfix é capaz de fazer relay para todas as
redes nas quais as interfaces de rede são pertencentes.
Sendo assim, através do parâmetro mynetworks, indica-se para quais
redes ou endereços IPs o relay ficará aberto, ou seja, restritas somente as redes ou
endereços informados.
A configuração é feita usando a seguinte sintaxe, conforme é mostrada
na Figura 26.
Figura 26 - Sintaxe do parâmetro mynetworks
O exemplo fica conforme mostra a Figura 27.
Figura 27 - Configuração do parâmetro mynetworks
_____________ 10 DMZ é um segmento de rede separado e com acesso altamente restrito.
mynetworks = rede/máscara, IP/máscara, rede/máscara, IP/máscara
dominio1.com.br, dominio2.com.br, dominio3.com.br
mynetworks = 127.0.0.0/8, 1.2.3.4/32, 192.168.1.0/24, 5.6.7.8/32
46
No exemplo anterior, o Postfix foi configurado para fazer relay para a
rede da interface loopback, para o endereço IP 1.2.3.4, para toda a rede interna
192.168.1.0 com a máscara de rede 255.255.255.0, 24 bits usados para a rede, por
isso a notação /24, conhecida como notação CIDR (Classless Inter-Domain
Routing), e para o endereço IP 5.6.7.8.
A notação /32, ou melhor, notação CIDR, é usada para os endereços
IPs. Esta notação significa que todos os bits de rede estão sendo usados para a
máscara de rede, ou seja, trata-se de um único endereço IP e não de uma rede
inteira.
4.2.3 Parâmetro - Myhostname
Todo o host numa rede possui um nome. Um host dedicado usado
como servidor de e-mail deve ter um nome. Sendo assim, os hosts que fornecem o
serviço de troca de mensagens tem a necessidade de um hostname (nome do host
configurado), uma vez que a integração entre o MTA e o serviço de resolução de
nomes, o DNS passa ser essencial para o funcionamento correto do serviço de
entrega das mensagens.
O parâmetro myhostname é o que define o nome de domínio
totalmente qualificado, ou seja, FQDN (Fully Qualified Domain Name), do host local
onde o Postfix encontra-se em execução. Apesar de parecer irrelevante, uma vez
que o Postfix já assume, por padrão, como valor para o parâmetro myhostname o
nome do host local, a necessidade de se especificar explicitamente o hostname
onde o Postfix está em execução é importante e, às vezes é necessária. Há casos
onde essa configuração é extremamente importante, senão necessária, seria caso o
nome da máquina não estivesse em formato totalmente qualificado (hostname +
nome de domínio) ou esta você estivesse executando o Postfix em uma interface
virtual.
A sintaxe do parâmetro myhostname é mostrada na Figura 28.
47
Figura 28 - Sintaxe do parâmetro myhostname
Por exemplo, caso o servidor de e-mail e possuísse o nome de mx1 e
fizesse parte do domínio exemplo.com.br, o parâmetro myhostname seria definido
como mostra a Figura 29.
Figura 29 - Configuração do parâmetro myhostname
4.2.4 Parâmetro - Mydomain
O parâmetro mydomain não necessita ser definido explicitamente. O
Postfix assume como valor o nome do domínio padrão do host no qual o mesmo
está sendo executado.
No exemplo citado, hostname.mx1.exemplo.com.br, o Postfix
assumiria como valor para o parâmetro mydomain, caso o mesmo não fosse
explicitamente definido, o valor exemplo. com.br.
Para definir o parâmetro mydomain, a seguinte sintaxe deve ser
usada, como mostra a Figura 30.
Figura 30 - Sintaxe do parâmetro mydomain
Usando domínio de exemplo, exemplo.com.br, a definição do
parâmetro mydomain fica conforme é mostrado na Figura 31.
Figura 31 - Configuração do parâmetro mydomain
myhostname = hostname.domain
myhostname = mx1.exemplo.com.br
mydomain = exemplo.com.br
mydomain = domínio
48
4.2.5 Parâmetro - inet_interfaces
A configuração padrão do Postfix é ouvir em todas as interfaces de
rede que o host possui instalada, é comum utilizar o parâmetro inet_interfaces
para definir em quais interfaces de rede o serviço SMTP será escutado.
Para isso, deve-se definir o parâmetro inet_interfaces no Postfix. A
sintaxe é mostrada na Figura 32.
Figura 32 - Sintaxe do parâmetro inet_interfaces
No exemplo da Figura 33, os parâmetros são definidos como valor para
o parâmetro mydestination.
Figura 33 - Configuração do parâmetro inet_interfaces
Esta configuração faz com que o Postfix aceite as requisições de
clientes SMTP na porta 25 no endereço IP da interface de rede que resolva para o
nome mx1.exemplo.com.br, onde este é valor do parâmetro myhostname
especificado, e na porta 25 da interface de rede loopback. Sendo assim para
funcionar corretamente os hostnames dessas interfaces de rede devem estar
corretamente configurados no arquivo /etc/hosts atribuindo os hostnames aos
endereços IPs de cada interface de rede existente.
4.2.6 Configuração do arquivo master.cf
O arquivo master.cf, Figura 34, é simplesmente uma tabela que o
processo máster faz a leitura para comandar os outros sub-processos. O Postfix
tem a funcionalidade de enjaular um processo. Para que seja habilitada a
funcionalidade basta apenas mudar o flag chroot para y, isto é, yes, a jaula e
inet_interfaces = hostname.dominio, hostvirtual.dominiovirtual
inet_interfaces = $myhostname, localhost.$mydomain
49
atribuída dentro do diretório de spool. A coluna maxproc permite limitar o número
máximo de instâncias simultâneas de um processo que podem ficar executando.
Assim pode-se observar a possibilidade de aumentar ou diminuir o limite de um tipo
específico de um sub-processo de acordo com as necessidades. Por padrão, ele
vem preparado para limitar 50 instâncias de cada processo. A coluna unpriv
informa se o processo roda como usuário postfix, com privilégios padrão, ou como
usuário root. A coluna wakeup serve para sub-processos que rodam em base
regular, independente de eventos no sistema. A coluna private informa se mais de
um processo pode acessar a mesma instância do serviço.
O mecanismo chroot é uma abreviação para change root, e ele foi
criado para alterar a raiz do filesystem para o ambiente ao qual será aplicado. Isto
significa que a barra inicial (/) em qualquer nome de caminho é tornada relativa ao
caminho chrooted. Por exemplo, se um arquivo chamado
/var/spool/postfix/local_das_mensagens, diretório onde o Postfix armazena as
mensagens, se for enjaulada os diretórios /var/spool/postfix, o arquivo no
ambiente da jaula será somente o local_das_mensagens (GROSSMANN, 2001).
O objetivo de fazer chroot é para criar uma "jaula" de proteção
teoricamente impenetrável, protegendo o que está no chroot para poder ler ou
modificar qualquer arquivo fora do ambiente do chroot. O mecanismo unpriv define
que todo processo que rodar dentro da jaula terá privilégios de usuário padrão.
Portanto, o processo ficará preso dentro da jaula com privilégios de usuário.
50
Figura 34 - Arquivo de configuração Master.cf
4.3 Antivírus ClamAV (Clam Antivírus)
O antivírus ClamAV é uma ferramenta de antivírus GPL para
ambientes UNIX, desenvolvida para verificar e-mails nos gateways, permitindo a
varreduras dos anexos dos e-mails. O pacote oferece um servidor multitarefa
bastante flexível, um scanner de linha de comando, e uma ferramenta para
atualização automática pela Internet (KOJM, 2002).
O banco de dados ClamAV é sempre atualizado, garantindo que seja
feito à atualização pelo servidor. O ClamAV possui várias características importantes
entre elas (KOJM, 2002):
• scanner rápido e multitarefa;
• suporte a vários tipos de arquivos compactados nas extensões (Zip,
RAR -2.0, Tar, Gzip, Bzip2, MS OLE2, MS Cabinet Files, MS CHM -
# ======================================================================
#service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (50)
# ======================================================================
smtp inet n - y - - smtpd
#smtps inet n - y - - smtpd \
-o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes
#submission inet n - y - - smtpd \
-o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes
#628 inet n - n - - qmqpd
pickup fifo n - y 60 1 pickup
cleanup unix n - y - 0 cleanup
#qmgr fifo n - y 300 1 qmgr
qmgr fifo n - y 300 1 nqmgr
rewrite unix - - y - - trivial-rewrite
bounce unix - - y - 0 bounce
defer unix - - y - 0 bounce
flush unix n - y 1000? 0 flush
smtp unix - - y - - smtp
showq unix n - y - - showq
error unix - - y - - error
local unix - n n - - local
virtual unix - n n - - virtual
lmtp unix - - n - - lmtp
51
Compiled HTML, MS SZDD - compression format);
• scanner de linha de comando;
• atualização do banco de dados de vacinas;
• detecção de mais de 35000 vírus, worms, e trojans, incluindo
Microsoft Office e MacOffice vírus de macro;
• suporte nas principais plataformas de sistemas operacionais
(GNU/Linux, Solaris, FreeBSD, OpenBSD 2, AIX 4.1/4.2/4.3/5.1,
HPUX 11.0, SCO UNIX, IRIX 6.5.20f, Mac OS X, BeOS, Cobalt MIPS
boxes, Cygwin, Windows Services for Unix 3.5 (Interix)).
4.3.1 Configuração da atualização do banco de dados
O ClamAV usa a ferramenta freshclam que faz a atualização do banco
de dados no endereço database.clamav.net. Esse endereço possui vários
servidores associados, onde servidor DNS utiliza o algoritmo round-robin para o
balanceamento de carga, ou seja, seleciona automaticamente um banco de dados
geograficamente localizado mais próximo ao cliente, para realização de donwloads
de updates.
O ClamAV pode ser atualizado de duas formas:
Modo interativo ou linha de comando: a atualização é feita pelo
comando freshclam –d; ou através do crontab11 onde é feita a configuração para
realização da atualização automática. Mas antes de fazer a atualização deve realizar
a seguinte configuração. É recomendável ter um arquivo de log, para o registro dos
updates do ClamAV. No diretório /var/log, insira a permissão 600 no arquivo
freshclam.log, e com o usuário do ClamAV como proprietário do arquivo, conforme
mostra a Figura 35.
A outra recomendação é indicar o local e nome do arquivo de log
criado na diretiva UpdateLogFile do arquivo de configuração freshclam.conf. Com
estas recomendações seguidas, pode-se executar o programa FreshClam no modo
interativo no comando freshclam –d.
_____________ 11 Crontab é um programa de agendamento de tarefas.
52
Figura 35 - Criação do arquivo de log do freshsclam
A outra opção é a forma automática. O crontab configurado para
realizar a atualização automática e silenciosa. Basta acrescentar uma linha ao
crontab do root ou do usuário do ClamAV, para verificar se há atualização a cada
hora, conforme mostra a Figura 36.
Figura 36 - Agendamento pelo Crontab
O caractere N deve ser um número entre 0 e 59. O recomendado é não
escolher múltiplos de 10, devido ao grande número de clientes que já usam este
intervalo de tempo. Caso a rede tenha servidor proxy para acesso a Internet, no
arquivo de configuração existe variáveis que devem ser preenchidas no arquivo
freshclam.conf, conforme mostra a Figura 37.
Figura 37 - Configuração do Proxy
4.4 Antispam – SpamAssassin
O antispam SpamAssassin, foi escrito e atualizado por Junstin Mason
a apartir de 2004 o SpamAssassin se tornou um projeto da Apache Software
Foundation. Antes de existir o SpamAssassin, existia o filtro filter.plx criado por Mark
Jeftovic’s. Este filtro de SPAM baseado em context/keyword, que utilizava as
técnicas básicas de antispam: pontuação de SPAM, regras para pontuação,
marcação de SPAM, entre outras. O Junstin Mason decidiu fazer alguns
# touch /var/log/freshclam.log
# chmod 600 /var/log/freshclam.log
# chown clamav
N * * * * /usr/local/bin/freshclam --quiet
HTTPProxyPassword is enabled. HTTPProxyServer myproxyserver.com HTTPProxyPort 1234 HTTPProxyUsername myusername HTTPProxyPassword mypass
53
melhoramentos e reescrever todo o código e daí originou o SpamAssassin,
(MASON, 2004).
A técnica usada pelo filtro Bayesiano faz análise de todo o conteúdo
da mensagem em busca de padrões suspeitos e, com base na identificação de
determinados padrões, utiliza estatística e probabilidade para fazer uma
classificação do que é ou não SPAM. Mas esta filtragem depende de aprendizagem
por estatística, e por isso terá sempre um risco, mesmo que gradativamente menor,
de classificação incorreta, isto é, da ocorrência de eventuais falso-positivos e falso-
negativos (D'Ávila, 2004).
O funcionamento do SpamAssassin é basicamente assim: O
SpamAssassin usa uma variedade de mecanismos incluindo análises de texto e
cabeçalho, filtro Bayesiano, listas de DNS bloqueados, e filtros de banco de dados
colaborativos, para filtrar os SPAMs antes que sejam entregues a caixa de correio
do usuário (MASON, 2004).
O SpamAssassin é uma solução que possui um conjunto poderoso de
ferramentas para pontuar e determinar se uma mensagem é ou não um SPAM.
Entre as verificações primárias, encontram-se:
• análise de cabeçalho: este filtro verifica se o Spammer está
mascarando a sua identidade para esconder o servidor de origem de
suas mensagens;
• análise do corpo do e-mail: o SpamAssassin tenta identificar,
baseado em ocorrências comuns de palavras, com esta informação o
SpamAssassin classifica a mensagem como SPAM ou HAM, isto é,
considerada como e-mail legítmo.
• análise da Blacklist: o SpamAssassin suporta consultas a listas
negras como mailabuse.org e ordb.org;
• análise de listas RBLs: o SpamAssassin faz o bloqueio de SPAM
baseados em listas negras de DNS.
54
4.4.1 Determinação da Pontuação pelo SpamAssassin
O Mailscanner Amavisd-new encaminha as mensagens para o
SpamAssassin para que as mensagens sejam analisadas. O SpamAssassin realiza
vários testes para determinar uma pontuação de SPAM para a mensagem. Quanto
maior for esta pontuação é maior a chance da mensagem ser considerada como um
SPAM. Em seguida, o SpamAssassin retorna a mensagem para o Amavisd-new,
para que se decida o que fazer com a mesma.
Os números negativos ou pequenos, próximo de zero, indicam que é
uma mensagem legítima, ou seja, classificada como ham.
4.5 Mailscanner – Amavisd-New (A MAil VIrus Scanner – New)
O Mailscanner Amavisd-new foi criado por Mark Martinec, na
Eslovênia. O Amavisd-new é uma versão aperfeiçoada em relação à versão
anterior. O Amavis que surgiu em 1997 e foi mantido até 2000 (MARTINEC, 2005).
O Amavisd-new atua entre um servidor de correio e um ou mais
verificadores de conteúdo de e-mail: como antivírus, ou o SpamAssassin. Sendo
assim o Amavisd-new, desempacota ou descompacta, caso seja necessário, todos
os anexos que fazem parte da mensagem e em seguida encaminha aos serviços de
controle de SPAM, SpamAssassin, e o antivírus, ClamAV, para que o conteúdo seja
verificado. Após todas as verificações, caso a mensagem caso seja considerada
legítima e sem vírus, ela é entregue ao Amavis-new que em seguinda entrega a
mensagem para a caixa de correio do usuário.
A comunicação entre o dispositivo de verificação de conteúdo e o
MTA, Amavisd-new e o Postfix é feita através do protocolo SMTP LMTP (Local Mail
Transfer Protocol).
55
4.5.1 Determinação da Pontuação pelo Amavisd-new
Após o SpamAssassin pontuar a mensagem, a mensagem é retornada
ao Amavisd-new, este irá determinar se a mensagem será considerada como
legítima ou SPAM. O Amavisd-new compara a pontuação do SPAM com três níveis
de valores numéricos, tag, tag2 e kill. Estes valores podem ser diferentes para cada
recipiente, o que ocasiona ações futuras diferentes para cada recipiente. Se
necessário, o processo de checagem do e-mail é quebrado em mais de uma
transação para acatar as diferentes preferências de cada recipiente. As pontuações
dos níveis serão abordadas a seguir (MARTINEC, 2005):
• Nível tag: Se a pontuação de SPAM da mensagem for igual ou
maior que o nível tag, campos de cabeçalho de SPAM (X-SPAM-
Status, X-SPAM-Level) são inseridos para os recipientes locais;
”undef” é interpretado como menor que qualquer pontuação de SPAM;
• Nível tag2: Se a pontuação de SPAM da mensagem for igual ou
maior que o nível tag2, os campos de cabeçalho de SPAM (X-SPAM-
Status, X-SPAM-Level, X-SPAM-Flag e XSPAM-Report) são inseridos
para os recipientes locais, e (X-SPAM-Flag e X-SPAM-Status)
recebem o valor ”YES”;
• Nível kill: Se a pontuação de SPAM da mensagem for igual ou
maior que o nível kill, a mensagem é bloqueada; e o remetente recebe
uma notificação de que a mensagem não pode ser entregue. Esta
notificação pode ser personalizada.
Quando o nível de pontuação alcançar a pontuação kill pode acarretar
em (MARTINEC, 2005):
• a mensagem é enviada para área de quarentena;
• o administrador de SPAM recebe uma notificação;
• contador Contentspammmsgs é incrementado;
• o remetente recebe uma notificação se o warnspamsender está
como true (verdadeiro) e $final_spam_destiny está como D_PASS;
• se a mensagem não for entregue, o remetente recebe uma
notificação de que a mensagem não pode ser entregue devido a
56
restrições.
Caso o nível de pontuação atinja o nível tag2 são adicionadas algumas
marcas na mensagem, nas quais o receptor ou o MUA podem decidir sobre o
destino da mensagem, como exemplo (MARTINEC, 2005):
• o campo de cabeçalho de assunto é modificado;
• os campos de cabeçalhos X-SPAM-Flag e X-SPAM-Status recebem
um Yes;
• e o log de e-mail indica ”Passed SPAM” ao invés de ”Passed
CLEAN”.
Caso o receptor ou seu MUA decida descartar um e-mail baseado na
marcação do tag2, não existe maneira de recuperar este e-mail da quarentena, o
remetente nunca será notificado, nem o administrador de SPAM. Para o MTA e o
Amavisd-new, a mensagem foi entregue com sucesso. Qualquer coisa que o MUA
fizer com o e-mail é de sua própria responsabilidade.
4.5.2 Área de quarentena
O e-mail é colocado na área de quarentena quando está infectado ou
que foi banido ou a sua pontuação de SPAM para pelo menos um recipiente está
acima ou igual ao nível kill. O parâmetro *quarantine_to para cada recipiente
(quando não está vazio), juntamente com o correspondente global
*_quarantine_method determina o local da quarentena (MARTINEC, 2005).
O parâmetro *_quarantine_method pode ser considerado um ajuste
estático, geralmente controla o formato e a localização da área de quarentena no
sistema. O parâmetro *quarantine_to pode ser considerado a parte dinâmica da
localização da área de quarentena, possivelmente afetada pelas configurações de
cada recipiente, ou seja, servindo para especificar a localização final, ex.: um
arquivo ou um mailbox no sistema.
Dependendo da categoria do correio, as seguintes variáveis
especificam o método da quarentena: $virus_quarantine_method,
57
$SPAM_quarantine_method, $banned_files_quarantine_method e o
$bad_header_quarantine_method. Uma maneira de desabilitar globalmente a
quarentena é especificar estas variáveis como ”undef” ou como uma string vazia.
Os métodos locais e o smtp: são usados para quarentena. O smtp:
atualmente não é usado para quarentena (é usado em envio e notificações).
Dependendo do método especificado (local/bsmtp/smtp) o ajuste do *quarantine_to
para cada recipiente adota diferentes semânticas e sintaxes, possivelmente
modificadas pela variável de configuração $QUARANTINEDIR.
O *quarantine_to é atualmente limitado em sua funcionalidade, sendo
usado apenas para desligar a área de quarentena para alguns usuários ou
subdomínios locais. Em configurações comuns a localização da quarentena (ex.:
um diretório ou uma mailbox dedicada) é a mesma para todos os recipientes. Se ao
menos um recipiente especificar o *quarantine_to, a mensagem será posta em
quarentena no local especificado, não importando o número de recipientes.
58
5 IMPLEMENTAÇÃO DO SERVIDOR DE E-MAIL SEGURO
A proposta deste capítulo é apresentar uma solução segura de um
servidor de e-mail. Dessa forma, este capítulo implementa um servidor e-mail com o
MTA Postfix e com as ferramentas de análise de conteúdo. Estas ferramentas são:
ClamAV, ferramenta de antivírus, SpamAssassin, ferramenta antispam e o
Amavisd-new, ferramenta de Mailscanner para verificação de conteúdo de e-mail. O
sistema operacional utilizado no estudo é o Linux da distribuição Redhat versão 8.
O acesso às mensagens será feito através do Dovecot utilizando o protocolo
IMAP4. Sendo assim, o estudo não abordará nenhuma instalação dos pacotes:
Linux Redhat, Postfix, Amavisd-new, ClamAV e SpamAssassin e Dovecot, mas
somente a sua configuração e comentários.
5.1 Sistema Operacional
O estudo utilizou o sistema operacional Linux da distribuição Redhat
8.0. A abordagem das próximas seções parte do princípio de que as instalações dos
programas já foram efetuadas, e que o servidor esteja conectado na rede protegida
com firewall, com acesso à Internet e as configurações básicas do sistema
operacional tenham sido realizadas previamente.
5.2 Configuração do MTA Postfix
Antes de realizar a configuração do Postfix deve ser feito a
desativação do MTA Sendmail, que vem instalado por padrão no sistema
operacional. A desativação do serviço é feita através da edição do arquivo
/etc/rc.conf , conforme mostrado na Figura 38.
Figura 38 - Desativação do MTA Sendmail
sendmail_enable=”NONE” sendmail_submit_enable=”NO” sendmail_outbound_enable=”NO” sendmail_msp_queue_enable=”NO”
59
A configuração do Postfix é realizada em dois arquivos, master.cf e o
main.cf, que normalmente estão localizados no diretório /etc/postfix/. A Figura 39
mostra os parâmetros que foram alterados com os respectivos comentários no
arquivo main.cf .
Figura 39 - Configuração do arquivo main.cf
Normalmente o parâmetro relay fica aberto por padrão, o analista de
segurança deve ficar atento com esta configuração para obter maior garantia de
segurança, conforme é mostrado na Figura 40.
#___________________________________main.cf________________________________
#### CAMINHOS
# Diretório para a fila do Postfix e a Jaula.
queue_directory = /var/spool/postfix
# Diretório dos arquivos executáveis do Postfix
command_directory = /usr/bin
# Diretório dos daemons do Postfix
daemon_directory = /usr/libexec/postfix
#### PRIVILÉGIOS DOS USUÁRIOS
# Usuário proprietário ao qual inicializa os daemons.
mail_owner = postfix
#### NOME DO SERVIDOR E DO DOMÍNIO
# Nome do servidor
myhostname = srv-mail.exemplo.com.br
# Domínio do servidor
mydomain = exemplo.com.br
#### ENVIO DAS MENSAGENS
# Domínio das mensagens enviadas.
myorigin = $mydomain
#### RECEBIMENTO DAS MENSAGENS
# Interface de rede que recebe e-mails.
inet_interface = all
# Domínios de recebimento de e-mails.
mydestination = $mydomain, $myhostname, localhost
#### USUÁRIOS DESCONHECIDOS
# Código de erro retornando quando recebe e-mail com destinatário
# desconhecido. 450 = tente novamente, 550 = e-mail rejeitado.
unknow_local_recipient_reject_code = 550
60
Figura 40 - Configuração do arquivo main.cf - Continuação
Como descrito no capítulo 4, o Postfix possui controle de mensagens
comerciais não solicitadas. A continuação do arquivo main.cf contempla a
configuração RBL e RHSBL que será melhor abordado posteriormente, como
mostra a Figura 41.
#___________________________________main.cf________________________________
#### CONFIGURAÇÂO DE RELAY
# Redes que podem fazer relay no servidor.
mynetworks = 192.168.0.0/24, 127.0.0.0/8
#### TAXA DE ENTRADA
# Pausa antes de aceitar uma nova mensagem quando a taxa de entrega
# excede a taxa de entrega.
#in_flow_delay = 1s
#### ALIASES
# Arquivo de aliases (apelidos, redirecionamento local).
# Quando o arquivo for modificado deve-se executar “newsaliases”.
alias_maps = hash:/etc/aliases
#### CONFIGURAÇÕES DIVERSAS
# O servidor Biff envia notificações de mensagens novas.
biff = no
# Banner exibido quando se conecta ao servidor de e-mail.
smtpd_banner = $myhostname ESMTP $mail_name
#### MAILBOX
# Parâmetro opcional que especifica o home do usuário
#home_mailbox = Mailbox
# Diretório onde ficam as caixas de mensagens
#mail_spool_directory = /var/mail
# Programa externo opcional para fazer a entrega local.
#mailbox_command = /local/do/procmail
# Tamanho máximo em bytes das caixas de correio.
#mailbox_size_limit = 51200000
#### LIMITES DE TAMANHO
# Tamanho da mensagem original que é retornada quando da notificação de
#erro na entrega.
#bounce_size_limit = 50000
61
Figura 41 - Configuração do arquivo main.cf – Continuação
#___________________________________main.cf________________________________
# Tamanho máximo do cabeçalho da mensagem. O tamanho excedente será
# descartado
#header_size_limit = 102400
# Tamanho máximo do e-mail, em bytes.
#message_size_limit = 10240000
#### FILTRO ANTISPAM
# Limite de destinatários por mensagem.
#smtpd_recipient_limit = 1000
# Restringe a conexão de determinados IPs.
smtpd_client_restrictions =
reject_rbl_client relays.ordb.org,
reject_rbl_client sbl-xbl.spamhaus.org,
reject_rbl_client bl.spamcop.net,
# Restringe a conexão de determinados hostnames.
reject_rhsbl_client blackhole.securysage.com,
permit
# Restringe o envio por determinados remetentes.
smtp_sender_restrictions =
reject_unknow_sender_domain,
reject_rhsbl_sender blackhole.securitysage.com,
permit
# Restringe o envio para determinados destinatários.
smtp_recipient_restrictions =
permit_mynetworks,
reject_unauth_destination,
permit
#### CONFIGURAÇÕES DE INSTALAÇÃO
# Caminho completo do commando sendmail, para compatibilidade.
sendmail_path = /usr/sbin/sendmail
# Caminho completo do commando newsaliases do Postfix.
newaliases_path = /usr/bin/newsaliases
# Caminho completo de comando mailq do Postfix.
mailq_path = /usr/bin/mailq
# Grupo usado para submissão de e-mail e gerenciamento de filas.
setgid_group = postdrop
# Diretório das manpages.
manpage_directory = /usr/local/man
# Diretório dos exemplos de configuração.
sample_directory = /etc/postfix
# Diretório dos arquivos README.
readme_directory = no
62
O arquivo master.cf, neste momento, não exigirá mudanças para o
funcionamento básico do Postfix, este arquivo será melhor abordado quando for
feita a configuração do Amavisd-new e o restante das configurações, conforme
mostrado na Figura 42.
Figura 42 - Configuração do arquivo master.cf
Após estas configurações, poderá ser realizado a inicialização do
Postfix, utilizando-se o seguinte comando:
service postfix start
Após a inicialização do Postfix é recomendável verificar o conteúdo do
arquivo de log, /var/log/mail se houve erros. O teste para verificar disponibilidade
do daemon do Postfix é feito pelo Telnet na porta 25, conforme mostra a Figura 43.
Este teste comprova se o serviço SMTP está ativo e operante na porta 25.
#_________________________________master.cf________________________________
# =========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# =========================================================================
smtp inet n - n - - smtpd
#smtps inet n - n - - smtpd
# -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes
#submission inet n - n - - smtpd
# -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes
#628 inet n - n - - qmqpd
pickup fifo n - n 60 1 pickup
cleanup unix n - n - 0 cleanup
#qmgr fifo n - n 300 1 qmgr
qmgr fifo n - n 300 1 nqmgr
#tlsmgr fifo - - n 300 1 tlsmgr
rewrite unix - - n - - trivial-rewrite
bounce unix - - n - 0 bounce
defer unix - - n - 0 bounce
flush unix n - n 1000? 0 flush
proxymap unix - - n - - proxymap
smtp unix - - n - - smtp
relay unix - - n - - smtp
# -o smtp_helo_timeout=5 -o smtp_connect_timeout=5
showq unix n - n - - showq
error unix - - n - - error
local unix - n n - - local
virtual unix - n n - - virtual
lmtp unix - - n - - lmtp
63
Figura 43 - Teste para verificação da disponibilidade do serviço SMTP
5.3 Configuração do Mailscanner Amavisd-new
A instalação do Amavisd-new necessita que alguns pacotes externos
sejam previamente instalados para auxiliar no desarquivamento, descompactação e
decodificação das mensagens caso estejam nestes formatos. Estes pacotes estão
descritos na Tabela 1 com os respectivos links para download.
Tabela 1 - Pacotes externos e dependências do Perl para Amavisd-new (SPENNEBERG, 2005)
# telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is ’^]’.
220 srv-mail.examplo.com.br ESMTP Postfix
quit
221 Bye
Connection closed by foreign host.
arc arc arc-5.21e-1.62rm.src.rpm http://rmorales.modwest.com/rpms/amavis/#arc-notesnomarch nomarch file-3.33-0.1.62rm.src.rpm http://rmorales.modwest.com/rpms/amavis/#arc-notes
bzip2 bzip2 bzip2-1.0.2-5.i386.rpm http://rpmfind.netfile file file-3.37-8.i386.rpm http://rpmfind.netlha lha lha-1.14i-7.i386.rpm http://rpmfind.net
compress ncompress ncompress-4.2.4-31.i386.rpm http://rpmfind.netunarj unarj unarj-2.43-12.i386.rpm http://rpmfind.netunrar unrar unrar-2.71-1.62rm.src.rpm http://rmorales.modwest.com/rpms/amavis/#arc-noteszoo zoo perl-Archive-Tar-0.22-2.62rm.amavis.src http://rmorales.modwest.com/rpms/amavis/#arc-notes
Archive::Tar perl-Archive-Tar Archive-Tar-1.26.tar http://search.cpan.org/~kane/Archive-Tar-1.25/Archive::Zip perl-Archive-Zip perl-Archive-Zip-1.01-1.62rm.src http://rmorales.modwest.com/rpms/amavis/#arc-notes
Compress::Zlib perl-Compress-Zlib Compress-Zlib-1.41.tar http://search.cpan.org/dist/Compress-Zlib/Convert::TNEF perl-Convert-TNEF perl-Convert-UUlib-0.201-4.62rm.src.rpm http://rmorales.modwest.com/rpms/amavis/#arc-notes
IO::stringy perl-IO-stringy perl-IO-stringy-2.108-1.62rm.src.rpm http://rmorales.modwest.com/rpms/amavis/#arc-noteslibnet perl-libnet perl-libnet-1.12-7.62rm.src.rpm http://rmorales.modwest.com/rpms/amavis/#arc-notes
MailTools perl-MailTools perl-MailTools-1.15-1.62rm.src http://rmorales.modwest.com/rpms/amavis/#arc-notesMIME::Base64 perl-MIME-Base64 perl-MIME-Base64-2.12-5.1.62rm.src.rpm http://rmorales.modwest.com/rpms/amavis/#arc-notes
MIME::tools perl-MIME-tools perl-MIME-tools-5.411-1.62rm.src.rpm http://rmorales.modwest.com/rpms/amavis/#arc-notesUnix::Syslog perl-Unix-Syslog perl-Unix-Syslog-0.98-1.62rm.src http://rmorales.modwest.com/rpms/amavis/#arc-notesNet::Server perl-Net-Server perl-Net-Server-0.84-1.62rm.src http://rmorales.modwest.com/rpms/amavis/#arc-notes
Time::HiRes perl-Time-HiRes perl-Time-HiRes-1.20-23.i386.rpm http://rpmfind.netDigest::MD5 perl-Digest-MD5 perl-5.8.0-55.i386.rpm http://rpmfind.net
Mail::SpamAssassin SpamAssassin spamassassin-2.31-16.i386.rpm http://rpmfind.netRazor razor-agents razor-agents-1.20-1.62rm.src.rpm http://rmorales.modwest.com/rpms/amavis/#arc-notes
Digest::SHA1 perl-Digest-SHA1 perl-Digest-SHA1-2.01-6.i386.rpm http://rpmfind.netDigest::HMAC perl-Digest-HMAC perl-Digest-HMAC-1.01-8.noarch.rpm http://rpmfind.net
Net::DNS perl-Net-DNS perl-Net-DNS-0.24-1.62rm.src.rpm http://rmorales.modwest.com/rpms/amavis/#arc-notes
Dependências: Programas Externos
Nome do pacote RPM Versão do Pacote RPM Link para download do Pacote
Dependências: Módulos Perl
Nome do pacote RPM Versão do Pacote RPM Link para download do Pacote
64
Após a instalação de todos os pacotes externos auxiliares é feita a
instalação do Amavisd-new, como mencionado anteriormente, não será abordado
no estudo. O arquivo de configuração do Amavisd-new é o /etc/amavisd.conf,
Figura 44. Os parâmetros são simples e documentados, são explicados com
comentários somente os parâmetros que foram modificados.
Figura 44 - Configuração do arquivo amavisd.conf
#____________________________amavisd.conf________________________
### amavisd.conf
# Hostname e Domain.
$mydomain = ‘srv-mail.exemplo.com.br’;
# Para a integração do Amavis-new com Spamassassin deve-se comentar
# a linha a seguir.
# @bypass_spam_checks_acl = qw( . );
# Para a integração do Amavis-new com Clamav deve-se comentar
# a linha a seguir.
# @bypass_virus_checks_acl = qw( . );
# Para a integração do Amavis-new com ClamAV deve retirar o
# comentario das linhas a seguir.
[‘Clam Antivírus-clamd’,
\&ask_daemon, [“CONTSCAN ()\n*, ‘/var/amavis/clamd’],
qr/\bOK$/, qr/\bFOUND$/,
qr/^.*?: (Infected Arquive)(.*)FOUNDS/},
qr’.\.(ade|adp|bas|bat|chm|cmd|com|cpl|crt|exe|hlp|hta|inf|ins|isp|
js|jse|lnk|mdb|mde|msc|msi|msp|mst|pcd|pif|reg|scr|sct|shs|shb|vb|
vbe|vbs|wsc|wsh)$’ix,
# Inserir a seguinte linha para notificação ao administrador de
# sistema.
$hdrfrom_notify_sender = ‘Antivirus <[email protected]’;
#Após a verificação do conteúdo pelo Amavisd-new e a mensagem não
#tiver vírus. A mensagem é encaminhada para o Postfix na porta 10025
#que repassará para cada cada caixa de dorreio.
$forward_method = ’smtp:127.0.0.1:10025’;
# O administrador recebe uma notificação para que a mensagem seja
# analisada. Evitando falsos positivos
$final_spam_destiny = D_PASS;
#A mensagem é entregue ao usuário
$sa_tag_level_deflt = 4.0;
#Se a pontuação de SPAM da mensagem for igual ou maior que kill,
#a mensagem é bloqueada; e o remetente recebe uma notificação
$sa_tag2_level_deflt = 6.3;
$sa_kill_level_deflt = $sa_tag2_level_deflt;
65
Neste momento será necessário configurar o Postfix para se
comunicar com o Amavisd-new. Para que o Postfix comunique-se com o Amavisd-
new, insere-se na última linha do arquivo main.cf um filtro de conteúdo para
integração do Postfix com o Amavisd-new, conforme mostra a Figura 45.
Figura 45 - Configuração do arquivo main.cf para integração com o Amavisd-new
Este filtro também foi acrescentado com os parâmetros no final do
arquivo master.cf para que a integração como Amavisd-new seja realizada,
conforme mostra a Figura 46.
Figura 46 - Configuração do arquivo master.cf para integração com o Amavisd-new
#___________________________________main.cf________________________________
###### Parâmetros do arquivo foram suprimidos intencionalmente por questões
# de espaço
#### Integração do Postfix com o Amavisd-new
content_filter = smtp-amavis:[localhost]:10024
#_________________________________master.cf________________________________
# =========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# =========================================================================
###### Parâmetros do arquivo foram suprimidos intencionalmente por questões
# de espaço.
#### Integração do Postfix com o Amavisd-new
smtp-amavis unix - - y - 2 smtp
-o smtp_data_done_timeout=1200
-o disable_dns_lookups=yes
127.0.0.1:10025 inet n - y - - smtpd
-o content_filter=
-o local_recipient_maps=
-o relay_recipient_maps=
-o smtpd_restriction_classes=
-o smtpd_client_restrictions=
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o mynetworks=127.0.0.0/8
-o strict_rfc821_envelopes=yes
66
Este recurso funciona com o Postfix repassando todas a mensagens
para o Amavisd-new na porta 1024 para fazer a verificação de conteúdo e anexos.
Após a verificação do conteúdo o Amavisd-new o e-mail é enviado para o
SpamAssassin, através do módulo Perl mail::spamassassin, para verificar se a
mensagem é SPAM, se a mensagem não for SPAM o Amavisd-new repassa a
mensagem ao ClamAV para verificar os anexos. Se os anexos não tiverem vírus, a
mensagem é enviada ao Postfix na porta 10025, que repassará para cada caixa de
correio.
Após a instalação e configuração do Amavisd-new, falta conferir se
está funcionando corretamente. Para isto é feito um teste através do Telnet na porta
10024. Esta porta foi configurada no arquivo /etc/amavisd.conf para ser padrão,
conforme é mostrado na Figura 47.
Figura 47 - Testando a porta 10024 do Amavisd-new
5.4 Configuração do Antivírus ClamAV
Para que o ClamAv pudesse ser instalado foi necessário que fossem
previamente instalados os seguintes pacotes: zlib, zlib-devel e compilador gcc,
bzip2, bzip2-devel library e o GNU MP 3, no caso deste pacote é muito importante
porque permite que o freshclam verifique as assinaturas digitais das bases de
dados do vírus. Estes pacotes de instalação podem ser encontrados no site
http://rpmfind.net.
Em seguida deve-se fazer a configuração no ClamAV para integração
com o Amavisd-new. Editando o arquivo /usr/local/etc/clamav.conf para alterar o
parâmetro LocalSocket /var/clamav/clamd e User clamav para LocalSocket /var/
amavis/clamd, User vscan respectivamente, conforme mostra as Figuras 48 e 49.
# telnet localhost 10024
Trying 127.0.0.1...
Connected to localhost.
Escape character is ’^]’.
220 [127.0.0.1] ESMTP amavisd-new service ready
quit
221 2.0.0[127.0.0.1] amavisd-new closing transmission channel
Connection closed by foreign host.
67
Figura 48 - Configuração do arquivo clamav.conf
#_______________________________clamav.conf________________________________
### clamav.conf
# Arquivo de log.
LogFile /var/log/clamav/clamd.log
# Para permitirem múltiplas instâncias com o mesmo arquivo de log
#LogFileUnlock
# Tamanho máximo em bytes do arquivo de log. O valor 0 é ilimitado.
LogFileMaxSize 0
# Coloca a data e a hora em cada linha do log.
LogTime
# Usar o syslog.
#LogSyslog
# Aumenta o detalhamento do log.
#LogVerbose
# Caso desejado salvar o PID em arquivo.
#PidFile /var/run/clamd.pid
# Caso se desejada salvar arquivos .db.
DataDiretory /usr/local/share/clamav
# Caminho para o socket local.
LocalSocket /var/amavis/clamd
# Remove os sockets travados.
FixStaleSocket
# Porta TCP.
# TCPSocket 3310
# Endereço local para maior proteção.
TCPAddr 127.0.0.1
# Tamanho máximo da fila de conexões pendentes.
#MaxConnectionQueueLength 30
# Stream de entrada será salvo no disco antes de ser scanneado.
# StreamSaveToDisk
# Limite de tamanho do STREAM. Se excedido fecha a conexão.
StreamMaxLenth 10M
# Número máximo de threads simultâneas. O padrão é 5.
MaxThreads 20
# Tempo máximo em segundos para cada threads. O padrão é 180.
ThreadTimeout 500
# Profundidade máxima de varredura de diretórios.
MaxDirectoryRecursion 50
# Links simbólicos de diretórios.
#FollowDirectorySymlinks
# Links simbólicos de arquivos.
#FollowFileSymlinks
# Intervalo em segundos entre cada verificação da integridade
# interna. O Padrão é 3600.
#SelfCheck 600
# Comando executado quando um vírus é encontrado.
#VirusEvent /usr/local/bin/send_sms 123456789 “VIRUS ALERT: %f: %v”
68
Figura 49 - Configuração do arquivo clamav.conf – Continuação
Finalizadas todas alterações nos arquivos de configuração do serviço
do servidor de e-mail, deve-se reinicializar o serviço do Postfix, ClamAV e o
Amavisd-new, para que estes efetivem as novas configurações, conforme mostrado
na Figura 50.
Figura 50 - Inicialização dos serviços
#_______________________________clamav.conf________________________________
# Usuário sob o qual o sistema irá executar.
User vscan
# Habilita grupos adicionais se o usuario clamav participar de algum.
#AllowSupplementaryGroups
# Não roda em background.
#Foreground
# Não executa em backgroup.
#Debug
# Descomentar a linha seguir se for varrer arquivos de e-mail.
#Scanmail
# Comentar a linha a seguir para desabilitar a varredura de arquivos
ScanArchive
# Suporte a arquivos compactados RAR.
#ScanRAR
# Tamanho máximo de arquivo compactados.
ArchiveMaxFileSize 50M
# Recursão máxima em arquivos compactados.
ArchiveMaxRecursion 10
# Número máximo em da quantidade de arquivos compactados
ArchiveMaxFiles 1000
# Limita a memória para descompressão bzip2.
#ArchiveLimitMemoryUsage
# service clamd start
# service amavisd start
______________Outra Sessão Terminal___________
# service postfix reload
69
5.5 Finalizando a configuração e testando
Até este momento, não foi necessário fazer configurações para o
SpamAssassin, pois este foi instalado como um módulo Perl, Mail::spamassasin,
mencionado na sessão anterior. Por isso, os parâmetros já se encontram
configurados com os valores padrões para o funcionamento imediato. E será
apenas necessário realizar treinamento. O SpamAssassin deve ser treinado com
dois arquivos do treinamento que possuem aproximadamente 200 mensagens com
SPAM e 200 com ham. Para executar o treinamento foi utilizado o comando
mostrado na Figura 51.
Figura 51 - Treinamento do SpamAssassin
Após o treinamento poderá ser feito um teste para verificar a eficácia
do antispam. O teste consiste de enviar de uma mensagem simples, através de
Telnet na porta 10024, conforme mostra a Figura 52.
Figura 52 - Teste com a Mensagem Normal (DUCKLIN, 2003)
sa-learn --showdots --mbox --SPAM nomedoarquivodeSPAM
sa-learn --showdots --mbox --ham nomedoarquivodeham
# telnet 127.0.0.1 10024
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is ’^]’.
220 [127.0.0.1] ESMTP amavisd-new service ready
MAIL FROM:<[email protected]>
250 2.1.0 Sender [email protected] OK
RCPT TO:<postmaster>
250 2.1.5 Recipient postmaster OK
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: test1
test1
.
*** 250 2.6.0 Ok, id=31859-01, from MTA: 250 Ok: queued as 90B7F16F
70
E uma outra mensagem teste contendo uma assinatura do “teste” de
vírus EICAR3, pode ser visto na Figura 53.
Figura 53 - Teste com a Mensagem EICAR (DUCKLIN, 2003)
O próximo teste será para simulação de envio de uma mensagem
SPAM para o servidor, para isso, será necessária a troca de valores de alguns
parâmetros: $sa_tag2_level_deflt = 6.31 para 3; e $sa_kill_level_deflt = 6.31 para 4,
no arquivo /etc/amavisd.conf. Lembrando que esta troca é somente para
realização do teste e após o teste, os valores anteriores serão retornados.
A simulação consiste em que toda mensagem será considerada como
SPAM. Em seguida esta mensagem será enviada ao servidor com pontuação igual
a 3.94, este valor irá ultrapassar o nível tag2 que foi configurado. Isto permitirá que
a mensagem seja entregue na caixa postal do destinatário, com a marcação de
mensagem SPAM em seu cabeçalho, conforme demonstrado na Figura 54.
# telnet 127.0.0.1 10024
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is ’^]’.
220 [127.0.0.1] ESMTP amavisd-new service ready
MAIL FROM:<[email protected]>
250 2.1.0 Sender [email protected] OK
RCPT TO:<[email protected]>
250 2.1.5 Recipient [email protected] OK
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: teste de vírus EICAR
X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*
.
250 2.7.1 Ok, discarded, id=01485-01 - VIRUS: Eicar-Test-Signature
71
Figura 54 - Teste com a Mensagem com nível tag2
5.6 Configuração do Dovecot Imap
O IMAP Dovecot possui o código aberto foi desenvolvido para oferecer
recursos de segurança. O Dovecot trabalha com mbox padrão e outros formatos de
armazenamento de mensagens. O Dovecot é fácil de configurar e não requer
muitos ajustes na sua configuração (SIRAINEN, 2005). O arquivo da Figura 55
mostra os principais parâmetros modificados do arquivo dovecot.conf.
From [email protected] Wed Nov 17 17:13:52 2005
Return-Path: <[email protected]>
X-Original-To: [email protected]
Delivered-To: [email protected]
Received: from localhost (localhost [127.0.0.1])
by [email protected] (Postfix) with ESMTP id 522E617281
for <[email protected]>; Wed, 17 Nov 2005 17:13:52 -0800 (PST)
Received: from unknown ([127.0.0.1])
by localhost (united [127.0.0.1]) (amavisd-new, port 10024) with SMTP
id 01484-01 for <[email protected]>;
Wed, 17 Mar 1999 09:41:55 -0800 (PST)
Subject: ***SPAM*** teste
X-Virus-Scanned: amavisd-new at exemplo.com.br
X-SPAM-Status: Yes, hits=3.942 tagged_above=2 required=3 tests=ALL_TRUSTED,
EMAIL_ROT13, HTML_30_40, HTML_IMAGE_ONLY_24, HTML_MESSAGE,
HTML_MISSING_CTYPE, JOIN_MILLIONS, MISSING_DATE, OBSCURED_EMAIL
X-SPAM-Level: ***
X-SPAM-Flag: YES
Message-Id: <[email protected]>
Date: Wed, 17 Nov 2005 17:13:52 -0800 (PST)
From: [email protected]
To: undisclosed-recipients:;
72
Figura 55 - Configuração do arquivo dovecot.conf
Neste estudo não foi habilitado o protocolo POP3, somente o protocolo
IMAP4, por questões de segurança.
5.7 Configuração do SASL (Simple Authentication and Security Layer )
A configuração dos SASL no protocolo SMTP precisa do pacote
Cyrus-SASL seja instalado previamente no sistema operacional. A configuração do
mecanismo SASL é bem simples, mas antes precisa informar ao Cyrus-SASL qual o
mecanismo de autenticação será usado. Existem vários mecanismos, os mais
comuns são sasldb, shadow e saslauthd. O sasldb usa seu próprio banco de dados,
o shadow usa o do sistema e o saslauthd é um mecanismo que oferece suporte ao
LDAP, IMAP, entre outros.
Para configurar o Cyrus-SASL no Postfix basta editar o arquivo
/usr/local/lib/sasl2/smtpd.conf ou /usr/lib/sasl2/smtpd.conf, dependendo de
onde o Cyrus-SASL estiver instalado, como mostra a Figura 56.
Figura 56 - Configuração do SAS no arquivo smtpd.conf
pwcheck_method: sasldb
#________________________________dovecot.conf______________________________
protocols = imap imaps
ssl_disable = no
ssl_cert_file = /etc/ssl/certs/imapd.pem
ssl_key_file = /etc/ssl/certs/imapd.pem
ssl_parameters_regenerate = 0
disable_plaintext_auth = no
login_chroot = no
login_max_processes_count = 250
login_max_logging_users = 256
max_mail_processes = 1024
first_valid_uid = 100
default_mail_env = maildir:/maildir/%u
mail_full_filesystem_access = no
maildir_stat_dirs = no
mbox_locks = dotlock fcntl
73
Feito isso, altere o arquivo main.cf e adicione as seguintes linhas no
final do arquivo, como mostra a Figura 57.
Figura 57 - Configuração do SASL no arquivo main.cf
5.8 Configuração das blacklist RHSBL e RBLs
Para usar RHSBL e RBLs no Postfix, basta adicionar as macros
(reject_rbl_client e o endereço do domínio da RBL) na configuração
smtpd_client_restrictions. E para configurar RHSBLs e feito da mesma forma,
basta adicionar a macro (reject_rhsbl_sender e o endereço do da RHSBL) no
arquivo main.cf, conforme mostra a Figura 58.
#### Configurações do SASL
broken_sasl_auth_clients = yes
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
#### Aplicando as regras do SASL no smtpd
smtpd_recipient_restrictions = permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination
74
Figura 58 - Configuração das blacklist RHSBL e RBLs no main.cf
#___________________________________main.cf________________________________
###### Parâmetros do arquivo foram suprimidos intencionalmente por questões
# de espaço.
#### FILTRO ANTISPAM
# Limite de destinatários por mensagem.
#smtpd_recipient_limit = 1000
# Macros RBL e Macros RHSBL.
smtpd_client_restrictions =
reject_rbl_client relays.ordb.org,
reject_rbl_client sbl-xbl.spamhaus.org,
reject_rbl_client bl.spamcop.net,
reject_rhsbl_client blackhole.securysage.com,
permit
# Restringe o envio por determinados remetentes.
smtp_sender_restrictions =
reject_unknow_sender_domain,
# Restringe a conexão de determinados hostnames.
reject_rhsbl_sender blackhole.securitysage.com,
permit
# Restringe o envio para determinados destinatários.
smtp_recipient_restrictions =
permit_mynetworks,
reject_unauth_destination,
75
6 CONCLUSÃO
O crescimento da utilização da Internet nas últimas décadas trouxe
vários benefícios provocados pela popularização das novas tecnologias de
informática, porém surgiram problemas motivados por esses serviços, dentre eles, o
serviço de correio eletrônico.
Uma importante ameaça é a falta de segurança que permite qualquer
um ter acesso através de uma vulnerabilidade para ganhar acesso a informações
restritas entre as partes interessadas, podendo ser usada por pessoas não
autorizadas a qualquer fim. Entretanto, usando as boas práticas de segurança na
configuração de um servidor de e-mail minimiza as principais ameaças existentes.
Estas vulnerabilidades e as novas ferramentas adotadas pelos
Spammers motivam um esforço cada vez maior em busca de soluções e
tecnologias capazes de minimizar estas ameaças, por isso, os analistas de
segurança devem que ficar atentos às novas descobertas de vulnerabilidades, para
que trabalhos sejam implementados em tempo.
Sendo assim, este estudo apresentou as ferramentas de segurança da
informação que integram a solução proposta para o controle de vírus e SPAM em
servidores de e-mail. Foram apresentadas diversas ferramentas de segurança que
integram a solução. Para minimizar problemas ocasionados pelo recebimento de
mensagens não solicitadas SPAM e também acesso não autorizado.
O estudo também propõs uma implementação de uma solução segura
em um servidor de e-mail. Esta solução consiste de um MTA Postfix e com suas
ferramenta integrada de análise de conteúdo. A solução contemplou um filtro de
conteúdo de e-mail, o SpamAssassin, um mailscanner para verificação de anexos,
Amavisd-new e um antivírus, ClamAV.
Portanto, este estudo fornece mecanismos favoráveis na obtenção de
um ambiente seguro em servidores de e-mails que demanda maior segurança nos
dados, que permitiu o bom entendimento das vulnerabilidades e ameaças no
ambiente de correio eletrônico. Em relação à implementação segura pode-se
concluir que o ambiente fica mais seguro e reduz, significativamente o número de
mensagens não solicitadas.
76
No intuito de continuar a pesquisa nesta área de segurança, mas
especificamente em segurança em servidores de e-mail, serão apresentados a
seguir alguns trabalhos futuros que podem ser realizados na mesma abordagem ou
até mesmo evoluindo, dando continuidade a este trabalho.
6.1 Trabalhos Futuros
Uma sugestão para continuidade deste trabalho é a utilização de uma
topologia totalmente redundante para garantir a disponibilidade do ambiente e
permitir que o mesmo possa ser expandido à medida que a demanda for
aumentando, é necessária a criação de uma topologia modular que ofereça
redundância nos equipamentos e serviços de que o tempo de indisponibilidade seja
reduzido ao máximo.
Outra sugestão é a implementação deste ambiente de segurança
usando a plataforma Windows, para a comparação entre outras plataformas de
sistemas operacionais.
Outro trabalho, mais distante desta abordagem, é o desenvolvimento
de um protocolo para substituir o protocolo SMTP. Este novo protocolo deve
oferecer recursos que permita, durante a negociação entre servidores de e-mail, a
verificação do tipo de mensagem que se trata, comercial, pessoal ou SPAM, isto é,
tratando o SPAM na origem e o uso de certificados para se saber exatamente de
quem veio o e-mail, mecanismos de não repúdio e autenticidade, e também uma
criptografia forte para garantir a confidencialidade.
77
REFERÊNCIAS BIBLIOGRÁFICAS
CERT.BR. Centro de Estudos, Resposta e Tratamento de Incidentes de Segurança no Brasil. Disponível em: < http://www.nbso.nic.br/ > Acesso em: 23 ago. 2005. CRISPIN, M. Internet Message Access Protocol – RFC2060, Version 4rev 1 rev1, Washington, 1996. Disponível em: <http://www.ietf.org/rfc/rfc2060.txt>. Acesso em: 15 jul. 2005. CROCKER, D. Mailbox Names for Common Services, Roles and Functions - RFC 2142, Internet Mail Consortium, May 1997. Disponível em: <http://www.ietf.org/rfc/rfc2142.txt > . Acesso em: 7 set. 2005. D'ÁVILA, M.H. C. Em busca da ferramenta anti-SPAM ideal, Jun 2004 Disponível em: <http://www.mhavila.com.br/ >. Acesso em: 17 out. 2005. ______________ Márcio d'Ávila web site, 2005 Disponível em: <http://www.mhavila.com.br/link/security/sec-email.html>. Acesso em: 10 jul. 2005. DUCKLIN, P The Anti-Virus test file, May 2003 Disponível em: < http://www.eicar.org >. Acesso em: 13 set. 2005. GOVERNO FEDERAL. Guia Livre referencia de Migração o para Software Livre do Governo Federal, Versão Ipiranga 0.95 – beta, 2003. GROSSMANN, C.A.K., Chrooting daemons and system processes HOW-TO: mar 2001. Disponível em: < http://underlinux.com.br>. Acesso em: 17 out. 2005. HAMBRIDGE, S. A Set of Guidelines for Mass Unsolicited Mailings and Postings (SPAM*) - RFC2635. Disponível em: <http://www.ietf.org/rfc/rfc2635.txt>. Acesso em: 15 jul. 2005. HORMEL FOODS CORPORATION. SPAM - SPiced hAM - Family of Products Disponível em: <http://www.hormel.com> Acesso em: 22 ago. 2005. IBM; VENEMA,W. MTA Postfix, 1998. Disponível em: <http://www.postfix.org>. Acesso em: 01 out. 2005. INFOGUERRA: Tudo o que você queria saber sobre SPAM. Infoguerra, 2003 Disponível em: < http://www.infoguerra.com.br/index.php3?secao=artigos > Acesso em: 22 ago. 2005. KNIGHT, C. Sender Policy Framework - SPF Explained. Disponível em: <http://emailuniverse.com/ >. Acesso em: 10 jul. 2005. KOJM,T. Clam AntiVirus 0.87 - User Manual, 2002. Disponível em: <http://ClamAV.net/>. Acesso em: 01 out. 2005.
78
KUROSE, J.F; ROSS, W Redes de Computadores e a Internet: Uma nova abordagem 1. ed. São Paulo: Addison Wesley, 2003. MAPS – MAIL ABUSE PREVENTION SYSTEM, Nominating an IP address to the MAPS RBL. Disponível em: < http://www.mail-abuse.com/nominats_rbl.html> Acesso em: set. 2004. MARTINEC, M. A Mail Virus Scanner New, September 2005. Disponível em: < http://www.ijs.si/software/amavisd/ >. Acesso em: 01 out. 2005. MASON, J. SpamAssassin Prehistory. April 2004. Disponível em: <http://SPAMassassin.apache.org/prehistory>. Acesso em 01 out. 2005. MESSAGELABS ANTI-SPAM. Combat SPAM before it reaches your network. Disponível em: <http://www.messagelabs.com> Acesso em: 20 set. 2004. MYERS, J. ; ROSE, M. Post Office Protocol – RFC1939, Version 3, San Diego, 1996. Disponível em: <http://www.ietf.org/rfc/rfc1939.txt>. Acesso em: 15 jul. 2005. NBSO - NIC BR SECURITY OFFICE. Brazilian Computer Emergency Response Team Cartilha de Segurança para Internet, Parte IV: Fraudes na Internet. NIC BR Security Office. Versão 2.0, 11 mar de 2003. Disponível em: < http://www.nbso.nic.br/docs/cartilha/ > Acesso em: 22 ago. 2005. NORTHCUTT, S.; NOVAK, J; MCLACHLAN, D Segurança e Prevenção em Redes 1. ed. São Paulo: Berkeley, 2001. POSTEL,J.B. Simple Mail Transfer Protocol – RFC821,Marina de Rey, 1982. Disponível em: < http://www.ietf.org/rfc/rfc821.txt > Acesso em: 15 jul. 2005. SCRIMGER, R. et al. TCP/IP a Bíblia 2. ed. Rio de Janeiro: Campus, 2002. SIRAINEN, T. Dovecot Secure IMAP server. Disponível em: <http://dovecot.org/index.html > Acesso em: 17 out. 2005. SPENNEBERG, R., Implementing a SPAM and virus scanning mail server using RedHat Linux 8.0 and amavisd-new, Version 1.3, mar, 2004. Disponível em: < www.spenneberg.com >. Acesso em: 22 ago. 2005. TANENBAUM. A.S. Redes de Computadores 3.ed. Rio de Janeiro: Campus,1997 WINKMEDIA, P. E-mail ou correio eletrônico, A WINKMEDIA PROJECT, 2005. Disponível em: < http://pt.wikipedia.org > Acesso em: 31 out. 2005.