Solução Completa de Servidor de Email com Domínios e Usuários Virtuais (Debian Etch, Postfix, Mysql, Dovecot, DSpam, ClamAV, Postgrey, RBL) - Página 10

VII. Email Seguro

Em um mundo ideal, nossos usuários poderiam enviar/receber emails sempre que estivessem na internet, de qualquer lugar do mundo. Infelizmente, isso é incrivelmente inseguro… senhas estão sendo trocadas em texto claro através dos protocolos SMTP e IMAP, e isso significa que qualquer um que quisesse poderia simplesmente ‘espionar’ a senha.

Se seus usuários não precisam de acesso direto à solução de email, então não os dê! Não há sentido em se estressar com uma configuração de email seguro se tudo o que seus usuários precisam é Webmail! Basta tornar a conexão deles com o servidor de webmail segura e garantir que o servidor de webmail use uma conexão de rede segura ao se comunicar com seus servidores de email. Problema resolvido! Se, por outro lado, seus usuários realmente precisam da capacidade de enviar/receber emails pela internet sem usar webmail, bem, isso apenas torna as coisas mais difíceis. Não impossível, apenas difícil.

Então, aqui está o seu problema: SMTP e IMAP enviam senhas em texto claro. Você pode fazer com que eles enviem senhas usando MD5, mas o MD5 básico pode ser hackeado. Você pode fazer com que eles enviem senhas usando MD5CRYPT, mas então você está lidando com múltiplas implementações (sem mencionar o fato de que nem todos os clientes de email suportam senhas MD5). A solução? TLS (Transport Layer Security). Vamos configurar nossa solução para suportar uma conexão criptografada pela internet. Embora pudéssemos modificar alguns de nossos servidores existentes para lidar com isso, não há sentido em complicar demais suas configurações. Vamos apenas rodar um servidor separado para lidar com tudo isso: secure-mail.example.com

NOTA: No cenário original, a pequena empresa tinha múltiplos endereços IP estáticos. Como esse é o caso, conseguimos rodar SMTP+TLS na porta 25, se você não tiver múltiplos endereços IP, então isso não é possível. A razão é simples: enquanto IMAPS (IMAP seguro) roda em uma porta diferente (993) do IMAP padrão (143), SMTP+TLS roda na MESMA porta que SMTP (25). Portanto, usar um firewall para roteamento baseado em portas permite que você execute servidores IMAP e IMAPS separados, mas nenhum firewall no mundo pode rotear a porta 25 para duas máquinas diferentes. Mesmo com tudo isso, você sempre poderia rodar SMTP+TLS em uma porta não padrão… na verdade, isso seria ainda mais seguro.

Então, com tudo isso em mente, vamos configurar um servidor de email seguro, que usa SMTP+TLS para enviar emails e IMAPS para recebê-los.

A. Certificados SSL

A forma mais simples de criptografia é ter um simples certificado autoassinado no servidor. Isso gerará uma mensagem de aviso quando os clientes se conectarem pela primeira vez, mas eles devem ser capazes de salvá-lo para uso futuro. Não é realmente seguro, já que qualquer um pode executar um ataque man-in-the-middle se você não salvar o certificado.

O próximo nível é usar um certificado de servidor assinado por uma Autoridade Certificadora (CA), seja uma comercial ou talvez a CA interna da empresa. Dessa forma, o certificado do servidor será confiável, e se você agora receber um aviso, há potencialmente algo errado acontecendo.

Por último, mas definitivamente não menos importante, é usar certificados de cliente para fazer login no servidor e usar um certificado de servidor para autenticar o servidor aos clientes. Isso é bastante seguro, mas não é suportado em todos os clientes de email. Thunderbird, entre outros, tem suporte para isso.

1. Certificado de servidor autoassinado

Primeiro crie os diretórios, crie a chave privada e, por último, crie o certificado.

# mkdir -p /etc/ssl/example.com/mailserver/  
# cd /etc/ssl/example.com/mailserver/  
# openssl genrsa 1024 > mail-key.pem  
# chmod 400 mail-key.pem  
# openssl req -new -x509 -nodes -sha1 -days 365 -key mail-key.pem > mail-cert.pem

Note que “Nome Comum (por exemplo, SEU nome)” DEVE corresponder ao nome do servidor, que neste caso é secure-mail.example.com

2. Certificado Assinado por CA

Usar um certificado assinado por uma CA real não é diferente de usar um autoassinado. É apenas mais um passo na criação do par de chaves. Se sua empresa tem sua própria CA, então eles devem emitir um certificado para o servidor de email. Uma busca no Google por “seja sua própria ca” lhe dará respostas suficientes para criar um você mesmo, se precisar.