Análise de Desempenho de Políticas de Segurança em Servidores de Correio Eletrônico

Transcrição

1 Análise de Desempenho de Políticas de Segurança em Servidores de Correio Eletrônico Gustavo R. Ramos, Thiago A. Siqueira, Adriano M. Cansian, Arnaldo Candido Jr. UNESP Universidade Estadual Paulista Júlio de Mesquita Filho - São José do Rio Preto {gustavo, thiago, adriano, arnaldo}@acmesecurity.org Resumo Devido à utilização do correio eletrônico na Internet por pessoas inescrupulosas, faz-se necessário definir uma política de segurança para o uso seguro e eficiente deste serviço. No entanto, a implementação dessas políticas pode degradar o desempenho dos servidores de correio eletrônico. Deve-se então escolher uma política que seja eficiente e não prejudique o desempenho do sistema. O presente artigo apresenta uma análise de desempenho dos servidores de correio eletrônico após a implementação de medidas de segurança contra a utilização indevida e mensagens não solicitadas. Apontando assim, medidas de segurança que não prejudiquem o desempenho dos servidores de correio eletrônico e um modelo de testes para medir como essas medidas afetam o desempenho do sistema. Abstract Due to the use of the electronic mail in the Internet by unscrupulous people, it is necessary to define a security policy to the use of electronic messages in a secure and efficient way. However, these security measures may degrade the system performance. So, we must choose an efficient security policy that does not degrade the system. This paper presents a performance analysis of the electronic mail system after the implementation of these security measures against the misuse and unwanted messages. Showing the security measures that do not degrade the electronic mail system performance and present a measurement performance model to it. 1. Introdução Todo sistema conectado a Internet está apto a enviar qualquer tipo de mensagem de correio eletrônico, e esse é o grande benefício trazido por esta tecnologia: a comunicação sem fronteiras de tempo ou espaço. Pode-se enviar um para qualquer pessoa que possua um endereço eletrônico, em qualquer lugar do globo a qualquer hora. Dessa forma, todos estes sistemas interligados estão suceptíveis a receber tentativas de conexão não autorizadas ou as chamadas mensagens não-solictadas ou spams [2]. Estima-se que cerca de 60% de todos os s enviados atualmente na Internet sejam spams. Isso representa cerca de 76 bilhões de mensagens que ocupam aproximadamente 10 petabytes de espaço de armazenamento [12]. O que primeiramente era utilizado para envio de propagandas a baixo custo, hoje é também utilizado para distribuir mensagens ilegais e programas maliciosos [2], muitas vezes violando a política de segurança das instituições envolvidas no transporte destas mensagens. Por isso, é necessário que as instituições conectadas a Internet definam uma política de segurança que esclareça os aspectos referentes à utilização do correio eletrônico, bem como implemente, de fato, esta política. Não existe uma solução única para o combate a utilização indevida, aos programas maliciosos e ao spam [2]. Por isso, foram desenvolvidas várias técnicas na tentativa de minimizar a quantidade de mensagens não-solicitadas e fornecer um nível de segurança adequado. Estas técnicas envolvem desde a definição de uma política de uso e segurança até a implementação destas políticas nos mais diversos servidores espalhados pelo globo. Todas as técnicas viáveis de combate aos vírus e spams devem ser aplicadas nos servidores MTA (Mail Transfer Agent) [9] - que são responsáveis pelo envio das mensagens de correio eletrônico - e possivelmente nos MUA (Mail User Agent), que são os programas utilizados pelos usuários do serviço de correio eletrônico [4]. Como já existe uma grande infra-estrutura implantada de MTAs e MUAs na Internet, toda e qualquer solução deve ser compatível com esta infra-estrutura, ou seja, deve ser compatível com o protocolo de envio e recebimento de s, o SMTP [9]. O grande desafio neste sentido é encontrar medidas de segurança que sejam adequadas e que não prejudiquem o desempenho dos servidores, principalmente os servidores que possuem um tráfego muito grande de mensagens. Neste artigo procuramos dar uma breve visão sobre como proteger um servidor de correio eletrônico (MTA) contra as ameaças atuais da Internet. E,

2 principalmente, mostrar uma política de segurança que seja adequada a implementação em servidores de correio eletrônico através dos testes de desempenho realizados. A definição de uma política de segurança é discutida na seção 2. Na seção 3 são apresentadas as tecnologias que podem ser implementadas nos servidores. A seção 4 apresenta uma implementação que mostra a capacidade e o desempenho de algumas soluções apresentadas na seção anterior, bem como os resultados obtidos durante a realização desses procedimentos e a análise desses resultados. As conclusões são descritas na seção 5, seguida dos agradecimentos e das referências utilizadas na elaboração deste artigo. 2. Política de Segurança Com o crescimento da utilização da Internet como meio de comunicação, as mensagens de correio eletrônico começaram a ser utilizadas como meio de comunicação oficial em algumas instituições, inclusive podendo ser utilizadas como provas em processos judiciais, evidenciando ainda mais a questão da segurança dos servidores de correio eletrônico. Todo sucesso em segurança de informação é alcançado através do planejamento. Neste caso, planejar significa identificar os pontos que devem ser protegidos. Após o planejamento é necessário implementar medidas de segurança adequadas. É dessa forma que são definidas e implementadas políticas de segurança [1]. Em se tratando dos servidores de correio eletrônico, a política de segurança deve definir o controle de acesso ao servidor, a política de usuários e de utilização e a política de acesso externo [11]. 2.1 Controle de Acesso ao Servidor O acesso ao servidor deve ser controlado e permitido somente a pessoas autorizadas. Tanto o acesso físico quanto o acesso aos dados e configuração. Essas medidas básicas garantem a integridade dos dados e posteriormente a confiabilidade dos mesmos. O não cumprimento desta primeira regra prejudica todas as outras medidas de segurança que possivelmente poderiam ser adotadas Política de Usuários e Utilização Os usuários do sistema devem saber exatamente o que é considerado como uso aceitável dos servidores, assim como não devem violar nenhuma das regras definidas na política de segurança. Nesta, pode também constar medidas que impossibilitem o envio de alguns tipos de mensagens, baseada em alguma regra existente na instituição a que pertence o servidor. É extremamente importante expor claramente essas regras aos usuários do sistema. Por exemplo, se haverá filtragem através de um anti-vírus nos servidores SMTP os usuários desse sistema devem saber e concordar com essa política Política de Acesso Externo Todo acesso externo para envio de s deve seguir uma política ainda mais rigorosa. Isso por que os servidores abertos (open relay) são geralmente utilizados para encobrir as evidências do envio de mensagens de correio eletrônico, possibilitando o envio de mensagens não solicitadas de forma anônima. É importante ressaltar que a implementação dos filtros e regras de transporte não devem bloquear as mensagens enviadas para os endereços definidos no RFC 2142 [3], tais como os endereços abuse@domínio.exemplo, security@domínio.exemplo, noc@domínio.exemplo e postmaster@domínio.exemplo. Assim, garante-se que as possíveis reclamações sejam recebidas e analisadas Boas Práticas de Segurança A utilização não autorizada de servidores de correio eletrônico é considerada roubo de recursos computacionais, além de prejudicar a imagem dos dois lados envolvidos - quem utiliza e quem deixa utilizar acarreta custos a instituição que, no caso, não implementou alguma política de segurança. Devido a esse fato, existem algumas regras definidas no RFC 2505 [7] que devem ser implementadas nestes servidores: Se o parâmetro RCPT TO: fornecido pelo cliente for um endereço (ou domínio) do qual o servidor MTA for responsável, então deve ser autorizado o transporte desta mensagem. Se o IP ou o FQDN (Fully Qualified Domain Name) do cliente SMTP for um endereço autorizado de acordo com a política definida previamente, então o servidor deve se encarregar do transporte do . Qualquer outra tentativa de utilização do servidor SMTP deve ser bloqueada e considerada como uma ação maliciosa ou intrusiva. Ainda de acordo com o RFC 2505 o transporte das mensagens do usuário deve ser prioritariamente recusado quando ainda está acontecendo o diálogo SMTP, ou seja, o usário enviou toda a mensagem ao SMTP (após o comando DATA ser completado), mas não recebeu um código de retorno de sucesso de envio (código 250 definido pelo protocolo SMTP). É neste momento que podem ser utilizadas regras diretamente no MTA. Quando a mensagem já estiver armazenada no servidor e o diálogo SMTP foi devidamente finalizado, podem ser realizados outros tipos de

3 filtragem, tais como a busca por arquivos anexados com vírus e conteúdo ilegal. A figura 1 mostra as duas fases onde podem ser aplicadas medidas de segurança e filtragem em um servidor SMTP. Cliente SMTP 250 OK 1 a Fase de Filtragem Servidor SMTP 2 a Fase de Filtragem Filtragem SMTP Mailbox Usuário Figura 1. Bloqueio e filtragem em servidores SMTP. Ou seja, as regras definidas na política de segurança podem ser aplicadas em duas situações diferentes, que implicam em algumas vantagens e desvantagens. Primeiramente, uma mensagem pode ser recusada antes de ser completado o diálogo SMTP (1ª Fase de filtragem) e então o erro deve ser tratado pelo usuário que a enviou. Isso proporciona um melhor desempenho do servidor evitando que a mensagem seja processada e armazenada. No entanto, muitas restrições nesta primeira etapa podem gerar uma grande quantidade de falsos-positivos (mensagens bloqueadas erroneamente), tornando o serviço de correio eletrônico pouco eficiente para os usuários finais. A filtragem nesta primeira fase pode também favorecer atacantes que queiram lançar ataques de negativa de serviço contra o servidor de correio eletrônico, como mostra [7]. Pode-se também realizar a filtragem em um momento posterior (2ª fase de filtragem). Neste caso a mensagem foi recebida com sucesso e pode ser submetida a vários tipos de filtros, por exemplo um anti-vírus, como veremos na seção 3. Para que a mensagem seja filtrada após ser recebida é necessário dispensar mais recursos computacionais do que aqueles já dispensados para o recebimento e armazenamento da mensagem. No caso de servidores de alto tráfego essa abordagem pode paralizar os serviços de correio eletrônico. Para resolver este problema é necessário implementar a filtragem em uma máquina diferente ou utilizar algum tipo de balanceamento de carga, com a desvantagem de elevar os custos de implementação. Na busca pela solulção destes problemas devemos encontrar medidas de segurança para bloquear uma grande parte das mensagens não solicitas na primeira fase de filtragem, diminuindo a quantidade de mensagens que deverão ser analisadas pelos filtros da segunda fase que demandam maior carga de processamento e conseqüentemente degradam o desempenho do sistema. Essa é a abordagem escolhida para a implementação neste trabalho. 3. TECNOLOGIAS Existem inúmeras tecnologias que foram desenvolvidas com o objetivo de proteger um servidor SMTP contra a utilização não autorizada, spams, vírus e s forjados. Infelizmente, nenhuma delas consegue atingir esse objetivo totalmente ou, senão, satisfatoriamente. Não existe uma solução definitiva e única para os problemas de segurança desses servidores. Muitas vezes devido ao alto tráfego de alguns servidores a implementação de todos os métodos mostrados a seguir poderia acarretar um alto custo de processamento, degradando o desempenho de todo o sistema. Dentre as diversas técnicas de proteger um servidor, existem duas maneiras principais. A primeira técnica é a filtragem de s após o recebimento destes pelo MTA. Podem ser efetuadas filtragens através dos dados encontrados no corpo da mensagem, dos dados dos cabeçalhos e também nos arquivos anexados (mime) nas mensagens. A segunda maneira de proteção dos servidores é através de listas onde constam endereços IP ou nomes de domínio que são considerados servidores abertos para envio indiscriminado de mensagens de correio eletrônico. Atualmente, os servidores brasileiros são considerados pelas principais listas de bloqueio internacionais como servidores potencialmente abertos ao envio indiscriminado de mensagens, o que pode causar alguns transtornos para os usuários dos sistemas bloqueados. Nas seguintes subseções, serão apresentadas algumas tecnologias de segurança existentes. A maioria destas tecnologias é aplicada na segunda fase de filtragem apresentada na seção anterior Filtros Os filtros são sistemas utilizados para identificar e rejeitar ou organizar os spams. Um spam rejeitado não chega a ser armazenado no disco do servidor. Em contrapartida, se uma mensagem não requisitada passa por esse tipo de filtro, ele poderá passar por uma classificação, a qual poderá marcá-la como sendo indesejada. Isso possibilita a organização das mesmas, separando-as, por exemplo, em pastas diferentes, segundo sua classificação. Estes filtros podem se encaixar em várias categorias, dependendo de como funcionam. Duas dessas categorias são descritas nas seções e Filtros Probabilísticos. São filtros que procuram no corpo da mensagem padrões que probabilisticamente classificam uma mensagem como spam, geralmente usando métodos bayesianos (Robinson, 2003). Estes padrões são baseados em palavras e características de escrita peculiares deste tipo de mensagem. Alguns destes filtros possuem

4 algum grau de aprendizado, muitas vezes utilizando inteligência artificial. Devido a adaptabilidade deste tipo de filtro, no início de sua utilização podem ser constatados vários falsos-positivos. Após algum tempo de utilização, o filtro se adapta aos s recebidos e pode chegar a filtrar cerca de 90% a 95% dos spams satisfatoriamente [13] Anti-vírus. Filtragem essencial devido a quantidade de vírus existentes atualmente, sua função é procurar por programas maliciosos que podem estar anexos às mensagens eletrônicas. Sua importância é classificar estas mensagens como portadoras de vírus. Se encontrado o vírus este não será entregue ao destinatário e o emissor pode ser avisado. Apesar dessa capacidade, não é desejável este alerta, afinal muitos worms se propagam pela rede através de . Desta forma, uma grande quantidade de mensagens de alerta seriam geradas a cada vírus detectado. A importância de associar este tipo de filtro a políticas de segurança é exatamente devido ao grande número de mensagem enviadas em massa com algum tipo de código malicioso associado à elas Listas de bloqueio São listas (conhecidas também como RBL 1 ) que contêm IP's ou domínios de máquinas que são remetentes de mensagens não solicitadas. Existem listas públicas onde podem ser reportados spams. Estas listas irão avaliar a veracidade da informação, baseada em dados fornecidos pelo denunciante. Sendo verídica, o IP denunciado é adicionado a esta lista. Dessa forma, os administradores de MTAs podem utilizá-las como fonte para buscar se o remetente de determinada mensagem é um potencial spammer 2. Com isto, o e- mail pode ser rejeitado logo no recebimento pelo servidor, não necessitando ser armazenado ou avaliado por outros filtros, dependendo da configuração do MTA. Assim, há economia de recursos de rede, processamento e espaço de armazenamento. Além das listas públicas, pode-se implementar soluções em que os próprios usuários podem criar suas listas de bloqueio. Recebendo um , pode-se adicionar o IP/domínio do remetente a esta lista, e, sempre que receber novamente uma mensagem com esta informação no cabeçalho, ela será classificada como spam. Esta é uma abordagem utilizada, por exemplo, no spamassassin Listas de bloqueio e permissão. Existe ainda 1 RBL: do inglês, Realtime Blackhole List. 2 Pessoa responável pelo envio indiscriminado e não solicitado de mensagens. 3 Spamassassin: mais informações em uma forma mais agressiva de bloqueio através de listas, que geralmente são chamadas de ACL (Access Control Lists). Nesta categoria de listas o usuário define que somente receberá mensagens de endereços anteriormente cadastrados (lista de permissão). Também será criada uma lista de bloqueio da qual todos os endereços listados serão automaticamente bloqueados. Se um usuário deseja enviar uma mensagem para uma pessoa que utiliza este tipo de bloqueio e o endereço deste usuário não consta em nenhuma das duas listas, o usuário será avisado que precisa contactar o dono do por outro meio de comunicação para que este libere o envio de mensagens adicionando uma nova entrada na lista de permissão. Outras formas de bloqueio que se baseiam nesta mesma abordagem foram desenvolvidas. Essas metodologias utilizam o desafio computacional ou humano para combater s enviados aleatoriamente. Estas tecnologias são pouco utilizadas por apresentarem um número elevado de limitações e incovenientes [5] Sender Policy Framework (SPF) O SPF Sender Policy Framework [6] é uma nova alternativa no combate aos s forjados. A abordagem desta tecnologia é verificar o domínio do remetente de cada . Sabendo o domínio, através de uma consulta DNS, é possível determinar se o servidor que está enviando a mensagem é o responsável pelo envio das mensagens do domínio. Sendo responsável, pode-se aceitar a mensagem. Não sendo, o provavelmente foi forjado. Para funcionar, o SPF deve ser configurado no DNS e o MTA deve ter suporte a esta tecnologia. Por ser novo, nem todos os MTAs possuem a capacidade de lidar com o SPF, mas,, em pouco tempo todos os MTAs terão suporte a esta tecnologia. 4. Implementação Uma política de segurança deve ser implementada em camadas, aplicando as medidas adequadas em cada uma delas e ponderando pontos fortes e fracos de cada medida de segurança escolhida. Dessa forma, é de responsabilidade do administrador avaliar cada umas das tecnologias e decidir como podem ser utilizadas em conjunto para diminuir a incidência de s indesejáveis e a utilização não autorizada. Durante o desenvolvimento deste trabalho escolhemos implementar algumas regras de bloqueio no MTA e dois métodos de filtragem: por conteúdo utilizando o Spamassassin e filtragem de vírus utilizando o

5 Clamav 4. Neste momento, não houve interesse em testar o funcionamento das outras tecnologias apresentadas neste trabalho. O caso do SPF, por exemplo, é especial pois depende da implementação em outros servidores para um teste com resultados mais específicos. Também não foi configurado no MTA listas de bloqueio públicas (RBL) pois o teste deveria envolver somente o próprio servidor de testes. Assim, não dependemos de servidores externos com políticas de segurança e uso diferente das definidas em nosso servidor de testes. No entanto, criamos uma lista própria de bloqueio. Os endereços desta lista foram configurados a partir da observação dos arquivos de auditoria (logs) do MTA e da consulta a listas de bloqueio públicas. Foram escolhidos para a implementação programas disponíveis sob a licença de uso GPL 5, ou seja, foi utilizado somente softwares de código-aberto. A única exceção é o Spamassassin que possui licença de uso Apache License 6. No primeiro momento medimos o desempenho do sistema sem qualquer método de filtragem. Posteriormente, medimos o desempenho do filtro anti-vírus e da filtragem de spam. Os resultados obtidos nesta análise estão descritos na seção 4.4. O servidor de testes foi conectado a Internet para que pudesse receber tentativas de utilização, o que foi observado em menos de 24 horas após o momento de conexão com o mundo exterior. É interessante observar também que não foi adicionado um registro MX no DNS apontando para o IP do servidor de testes, e portanto, a tentativa de conexão foi totalmente aleatória, mostrando mais uma vez a necessidade de segurança nestes servidores. A conexão com a Internet nos permitiu testar o desempenho das medidas de segurança implementadas na primeira fase de filtragem Postfix O servidor MTA escolhido foi o Postfix devido a sua flexibilidade de configuração e fácil integração com os filtros anti-spam e anti-vírus, além do melhor desempenho em relação aos MTAs mais utilizados atualmente, como o Sendmail. O Postfix, desenvolvido por Witse Z. Venema (Venema, 2004), possui uma configuração padrão que oferece um bom nível de segurança. No entanto, algumas regras também foram configuradas para que não fosse permitido o envio de mensagens de servidores sem DNS reverso e servidores que não seguem o protocolo definido pelo 4 Clamav: mais informações em: 5 GPL: GNU Public License, mais informações em: 6 Apache License: mais informações em: RFC 821. Mensagens que possuiam um endereço de remetente inválido, ou seja, sem domínio válido, também não foram aceitas. Essas regras permitiram, através do bloqueio de mensagens não válidas, implementar de forma eficiente as regras da segunda fase de filtragem. As opções mais importantes da configuração do arquivo main.cf do Postfix de acordo com a política escolhida são: smtpd_helo_required = yes smtpd_sender_restrictions = permit_mynetworks, reject_non_fqdn_sender, reject_unverified_recipient, reject_unknown_sender_domain strict_rfc821_envelopes = yes mime_header_checks = regexp=/etc/postfix/mime_checks É importante observar que as opções listadas acima, se utilizadas em sites de muito tráfego podem diminuir o desempenho do MTA de acordo com [15]. No entanto, como veremos a seguir, os testes feitos no laboratório mostraram um desempenho satisfatório do MTA, mesmo com essas opções configuradas. Também é importante configurar uma lista de bloqueio própria com endereços IP que são sempre utilizados como clientes de conexões não autorizadas. Essa implementação pode melhorar o desempenho do servidor. Ainda podem ser configuradas outras opções como a filtragem pelo conteúdo MIME das mensagens, que aceita em sua configuração expressões regulares para definir as mensagens que devem ou não serem filtradas. Nos testes em laboratório também utilizamos a filtragem de arquivos com extensões que poderiam conter algum tipo de código malicioso, tais como cpl, lnk e com. A regra mime_header_checks é responsável por esta checagem, assim como o arquivo mime_checks deve possuir uma expressão regular que identifique nos cabeçalhos mime estensões de arquivos com possíveis códigos maliciosos, e rejeite o transporte dessas mensagens. É importante definir esta política para não sobrecarregar o servidor na segunda fase de filtragem, onde foi adicionado o filtro anti-vírus. Mais detalhes sobre a configuração do Postfix podem ser obtidos na página oficial [15] Spamassassin O Spamassassin foi o software escolhido para realizar a checagem de mensagens não solicitadas. O software utiliza cinco métodos para classificar as

6 mensagens como spam ou não. Os métodos são: - Análise dos cabeçalhos das mensagens: buscam por informações inconsistentes nos cabeçalhos das mensagens. - Análise do Texto: busca por palavras chaves, no corpo da mensagem, que identificam uma mensagem como um possível spam. - Lista de bloqueio: os usuários do sistemas podem configurar suas próprias listas de bloqueio. - Classificação por aprendizado: onde é utilizado o aprendizado através de um filtro bayesiano. - Bases de dados de informações de spams conhecidos: algumas instituições coletam e distribuem informações a respeito de mensagens não solicitadas. O Spamassassin pode ser configurado para utilizar as informações dessas bases de dados. Todas estas técnicas são utilizadas para pontuar uma mensagem. Cada usuário pode definir um limite para que as mensagens sejam consideradas spam. A configuração padrão do Spamassassin não apresenta um desempenho satisfatório e portanto o desempenho esperado deverá ser testado para garantir a entrega das mensagens com um atraso mínimo para o usuário final. suporta nativo para os filtros escolhidos e devido a este fato é necessária uma interface de comunicação entre o MTA e os filtros. O Amavisd-new foi o programa escolhido que implementa esta interface e permite que a segunda fase de filtragem seja configurada e realizada com sucesso. Para maiores detalhes sobre a configuração do Amavid-new em conjunto com o Postfix e o Clamav pode ser obtido em [14]. Como o Amavis está sendo utilizado como uma interface entre o Postfix, o Clamav e o Spamassassin, é necessário conferir a configuração do Amavis para que o filtro anti-vírus seja aplicado primeiro e descartando a mensagem infectada tão logo for encontrado algum código malicioso, proporcionando um maior ganho de desempenho Procedimentos e Resultados Os testes utilizaram o programa Postal para gerar um tráfego controlado de mensagens de correio eletrônico para realizar as medidas de desempenho. Várias implementações e configurações foram testadas para garantir um desempenho satisfatório. A configuração padrão dos programas escolhidos suportou a filtragem de apenas 10 mensagens por Figura 2. Taxa de 45 mensagens por minuto com filtro anti-vírus e anti-spam Clamav Para a detecção de vírus nas mensagens foi utilizado o Clamav, que é capaz de identificar mais de tipos diferentes de vírus, trojans e worms. A escolha da utilização de um anti-vírus nos testes é devido a grande quantidade de s recebidos com algum tipo de código malicioso. O desempenho do anti-vírus nos testes foi satisfatório Amavisd-new O MTA escolhido para implementação não possui minuto, o que não é um desempenho considerado satisfatório. Foi necessário então medir o desempenho de outras configurações até chegar em um nível de desempenho considerado seguro e satisfatório para implementação em servidores de correio eletrônico. Para isso utilizamos um servidor com configuração de hardware Pentium III de 800 Mhz com 650 MB de memória RAM e com sistema operacional Debian GNU/Linux 3.0 r2 portando kernel versão Este servidor apresentou um desempenho, sem qualquer medida de segurança, superior a 500 mensagens por minuto. Já com a filtragem de vírus, alcançou-se um desempenho de 200 mensagens por minuto. Posteriormente implementamos a filtragem de

7 vírus e spam em conjunto e o desempenho máximo alcançado foi de 45 mensagens por minuto com atraso menor que 30 segundos na entrega das mensagens como pode ser visto na figura 2. Nesta figura observamos as mensagens recebidas pelo Postfix a partir das 15 horas (45 mensagens por minuto a metade do número de mensagens em verde) são re-enviadas para o Amavisd-new (mais 45 mensagens por minuto, em azul) que logo após analisadas são recebidas novamente pelo Postfix (total em verde). A taxa máxima obtida é mostrada em azul na figura Conclusão A regras de bloqueio implementadas na primeira fase e os filtros da segunda fase mostram-se eficientes no combate as tentativas de utilização não autorizada e envio de mensagens não solicitadas. Constatamos que as medidas diminuiram a quantidade de tentativas de conexão não autorizada e de mensagens não solicitadas recebidas pelos usuários do sistema. As medidas de segurança propostas e implementadas durante a realização deste trabalho mostraram-se adequadas a servidores com tráfego de até 50 mensagens por minuto (que é equivalente a aproximadamente mensagens por dia), considerando um atraso máximo inferior a 1 minuto na entrega das mensagens. Para alcançar um melhor desempenho utilizando as medidas de segurança apontadas neste artigo, é necessário utilizar uma estratégia de balanceamento de carga com dois ou mais servidores, o que é facilmente obtido através da interface de filtragem Amavisd-new. 6. Referências [1] Barman, S. Writing Information Security Policies. New Riders: Indianapolis, [2] CERT Coordination Center. bombing and spamming. Disponível em: < ml>. Securityfocus whitepaper. Disponível em: < Acessado em: 03 ago [6] Lentczner, M. Sender Policy Framework (SPF). IETF Internet Draft, May Disponível em: < [7] Lindberg, G. Anti-Spam Recommendations for SMTP MTAs. February Request for comments RFC Disponível em: < [8] Miles, W. A High-Availability High-Performance E- Mail Cluster. Proceedings of the 30 th annual ACM SIGUCCS conference on User services. p ACM Press: New York, [9] Klensin, J. Simple Mail Transport Protocol. April, Request for comments RFC Disponível em: < Acessado em: 03 ago [10] Robinson, G. A Statistical Approach to the Spam Problem. Linux Journal, March Disponível em: < [11] SANS Institue. The SANS Security Policy Project. Disponível em: < Acessado em: 01 ago [12] Sipior, J.C.; Ward, B.T.; Bonner, P.G. Should spam be on the menu? Communications of the ACM, vol 47, p [13] Spamassassin. Documentação Oficial do Spamassassin, Disponível em: < Acessado em: 03 ago [14] Spenneberg, R. Implementing a SPAM and virus scanning mail server using RedHat Linux 8. Fevereiro, Disponível em: < Acessado em: 01 ago [15] Venema, W.Z. The Postfix Home Page, Disponível em: < Acessado em: 03 ago [3] Crocker, D. Mailbox Names for Common Services, Roles and Functions. May Request for comments RFC Disponível em: < [4] Gburzynski, P.; Maitan, J. Fighting the SPAM wars: A R er Approach with Restrictive Aliasing. ACM Transactions on Internet Technology. Vol. 4, No. 1, February 2004, p [5] Krawetz, N. Anti-Spam Solutions and Security, Part 2.