Meus artigos: Testando a seguranca de um servidor de emails

De Ramoni

Artigo ainda em lapidação e aceitando sugestões. (contato via email).

Conteúdo 1 Introdução 2 Testes de disponibilidade 2.1 Limite de tempo idle 2.2 Conexões por IP 2.3 Connection Rate 2.4 Slow Down 2.5 Bounces 2.6 Limite de destinatários 2.7 Limite de tamanho da mensagem/anexos 3 Teste de open relay 4 Testes de identificação 4.1 Banner 4.2 Features 4.3 Mensagens de erro

Introdução

Muita gente esquece de configurar alguns detalhes no servidor de email que podem evitar problemas de disponibilidade, load alto, e ir parar em blacklists.

A idéia não é citar as restrições que você usar para fazer um anti-spam, mas sim testes e sugestões de como seu servidor deveria se comportar para que não seja uma vítima de um script kid na Internet.

Para terem idéia de como é importante testar, quando fui trabalhar em uma empresa de segurança eu constatei que todos os "appliances anti-spam" vendidos eram open relays... imagina se a empresa não fosse de segurança ??

Recomendo também que estes testes sejam feitos periódicamente, pois as vezes devido à uma mudança de configuração o servidor pode virar um Open Relay.

Testes de disponibilidade

Limite de tempo idle

Tempo idle é o tempo "à toa" que uma conexão pode permanecer estabelecida. Com um limite muito alto (ou pior, sem limite) você estará prendendo um processo/conexão à toa, que em momentos de alto tráfego você iria precisa dela disponível.

Teste: abra uma conexão com seu servidor, não transmita nada e veja em quanto tempo ele te derruba.

Sugestão: 1m (nem um péssimo link causa 1m de conexão idle)

Conexões por IP

Mais importante do que o número máximo de conexões ao servidor, é o número máximo de conexões simultâneas de um mesmo IP.

Se você não colocar este limite, um IP somente poderá lotar todas as conexões disponíveis impedindo que outros conectem nele. Isto, aliado à falta de tempo idle, tornaria possível um garoto conectado na internet via modem 28k tornar seu servidor indisponível abrindo todas as conexões possíveis e mantendo-as idle.

Teste: abra quantas conexões no servidor puder.

Sugestão: limite de 5, e também configuro o limite de 5 para entregas paralelas ao mesmo destino. Na minha opinião, um mesmo servidor abrir no meu mais de 5 conexões simultâneas é agressão.

Connection Rate

Para se proteger de scripts baseados em loops infinitos, também é recomendado que haja um limite do tipo de conexões, mensagens ou destinatários em função de cliente e tempo.

Eu sugiro que seja em função de conexão / ip / tempo. Se for em função de destinatário em vez de mensagem, você pode chegar ao limite muito cedo em caso de emails para vários destinatários. Em função de mensagem, vai depender de quantas mensagens você permite por conexão (sim, depois de um rset o servidor origem tem todo o direito de iniciar uma nova mensagem na mesma conexão, e é bom colocar u limite nisso também).

Teste: faça um loop simples infinito, com um script dentro que envia emails para o seu servidor (emails que ele aceite, claro).

Sugestão: use uma unidade de tempo baixa, para evitar problemas com bursts. Exemplo: 3 conexões por segundo de um mesmo cliente é alto demais. Mas se este limite for excedido, no próximo segundo você já estará aceitando conexões deste cliente novamente. Mails conexões em tempo maior podem causar problemas com bursts e você negar durante muito tempo novas conexões do mesmo IP.

Slow Down

Não configure slow downs em caso algum. Existem servidores que fornecem mecanismos para "dormir" durante as respostas caso erros sejam cometidos pelo cliente.

Sugestão: pense que em uma situação de alto volume de emails, você não vai querer ter 60 conexões sendo seguradas pelo seu servidor porque o cliente está mandando spam para um destinatário que não existe. Em uma situação de alto tráfego, você precisa mais é descartar logo quem está errando para livrar o processo para um próximo.

Bounces

Você não deve em caso algum receber um email que não possa entregar. Quando você bloqueia o email na conexão de recebimento, a responsabilidade de reportar o erro ao destinatário é do servidor origem que não concluiu a entrega. Quando você aceita um email, processa o mesmo (anti-vírus, anti-spam) e não consegue entregá-lo (quota excedida, destinatário inexistente etc) além de ter gasto banda recebendo o email, tempo de CPU processando, ainda vai ter que gerar um email de retorno para o remetente informando a falha na entrega. Esta notificação é exigida pela RFC.

Sugestão: não receba qualquer email que não possa ser entregue.

Limite de destinatários

Este depende exclusivamente de que tipo de software tratará o email depois.

Sugestão: depende da sua política, mas por favor, coloque um limite.

Limite de tamanho da mensagem/anexos

Outra que dependerá do software que vem depois. Tenha em mente o load que pode ser gerado para escanear arquivos grandes, ainda mais se forem compactados (cabe aí um limite de recursividade também) e as necessidades do seu ambiente.

Sugestão: email não é a melhor forma de se enviar uma ISO.

Teste de open relay

Relay consiste em entrega externa, repassar mensagem. Você deve ter o controle de quem usa o servidor para fazer relay. Seja autenticando os usuários na conexão SMTP ou especificando IPs de redes permitidas.

Teste1: a partir de um IP externo, conecte no servidor e envie um email para um domínio pelo qual ele não responda.

Teste2: faça o mesmo teste, mas especifique como remetente um email válido no servidor, se não for, especifique postmaster@nomedoservidor. Explicação: já vi gente que coloca o domínio ou o hostname como "whitelist" de remetente, podendo fazer relay.

Sugestão: não confie nem em IPs de rede, pois máquinas internas infectadas podem usar seu próprio servidor de emails para enviar spams/virus. Sugiro que se exija autenticação para o envio de qualquer email, o que criaria uma barreia a mais para as máquinas infectadas.

Sugestão melhor ainda: bloquear o smtp/25 internamente. Somente aceitar conexões na porta 25 quando vier da Internet. Internamente, você poderia obrigar todos a usarem 465 com SSL, além do que assim você ainda pode definir outros limites e rates no servidor para os processos SSMTP, priorizando os emails internos.

Testes de identificação

Banner

Não é muito legal você anunciar no banner do smtp algo do tipo: "Olá, eu sou o queijo suíço versão 8.x.x, procure um exploit para mim e volte mais tarde".

Observação: os firewall PIX da Cisco têm uma mania muito feia de interferir no SMTP (o que ele sabe sobre SMTP??) e "camuflar" o banner do servidor para **********************. Isso além de infringir a RFC 2821 (que diz que o servidor destino precisa se identificar com hostname e ESMTP caso suporte), ainda informa ao cliente que o firewall é um PIX.

Features

Devido às diferentes funcionalidades, ordem de exibição e formato, pode-se identificar o software de MTA pelo retorno dele no comando EHLO.

Sugestão: desabilite as extensões que não pretende usar. *Dependendo da extensão*, não é necessário anunciá-la no EHLO, então algumas você até pode manter, mas deve omití-las.

Mensagens de erro

Caso possível, customize as mensagens de erro. É possível saber qual software você está rodando por uma simples resposta a um comando inválido ou destinatário inexistente.