Introdução

Nesta seção, abordaremos como configurar a autenticação no Postfix e os métodos disponíveis para essa configuração. As configurações apresentadas não só ilustrarão o procedimento, mas também introduzirão conceitos que serão importantes para entender o funcionamento dos serviços e evitar confusões nas próximas seções.

Autenticação SMTP

A autenticação SMTP permite que o servidor de e-mail verifique a identidade do cliente, independentemente do endereço IP, antes de permitir o envio de mensagens. Isso ajuda a prevenir o envio de e-mails não autorizados e reduz a possibilidade de abuso, como o envio de spam. Servidores SMTP precisam decidir se um cliente SMTP está autorizado a enviar e-mails para destinos externos ou apenas para destinos pelos quais o servidor é responsável.

Normalmente, servidores SMTP aceitam e-mails para destinos externos se o endereço IP do cliente estiver na mesma rede que o IP do servidor. Clientes SMTP fora da rede do servidor SMTP precisam de uma forma diferente de obter privilégios de "mesma rede". O Postfix suporta autenticação SASL (RFC 4954, anteriormente RFC 2554) para permitir que um cliente SMTP remoto se autentique no servidor SMTP do Postfix, e que o cliente SMTP do Postfix se autentique em um servidor SMTP remoto. Uma vez autenticado, o servidor pode conceder ao cliente privilégios semelhantes aos de uma rede interna.

O Postfix não implementa SASL diretamente, mas usa implementações existentes (como a biblioteca Cyrus SASL) como blocos de construção. Isso significa que a configuração inclui arquivos específicos tanto para o Postfix quanto para a implementação SASL usada. A biblioteca Cyrus SASL contém um grande volume de código, e a segurança do Postfix é comparável à de outros sistemas de e-mail que utilizam essa biblioteca. O Dovecot é uma alternativa à Cyrus SASL que pode ser considerada.

usuários móveis

Usuários móveis (que são definidos no RFC 2977) precisam acessar os recursos de seu próprio domínio, independentemente de sua localização atual na Internet. Infelizmente, usuários móveis quase nunca usam o mesmo endereço IP e, além disso, o usuário móvel e o postmaster nunca saberão seus endereços IP com antecedência, tornando as regras baseadas em endereços IP estáticos inúteis.

Há várias maneiras de permitir acesso de retransmissão para usuários móveis: Autenticação SMTP, Retransmissão baseada em certificado e Redes privadas virtuais (VPNs) entre outros métodos.

A autenticação SMTP resolve o problema na raiz ao assegurar que apenas clientes autenticados e autorizados possam enviar e-mails através do servidor. Isso evita abusos e controle inadequado, que são os problemas principais que precisam ser resolvidos. Estas são as etapas básicas no método SMTP AUTH:

O servidor SMTP oferece SMTP AUTH para um cliente de e-mail.
O cliente passa suas credenciais para o servidor.
O servidor verifica as credenciais e permite a retransmissão se elas forem válidas.

A retransmissão baseada em certificado, é baseada na troca e validação de certificados de cliente TLS. Estas são as etapas básicas na retransmissão baseada em certificado:

O servidor SMTP oferece uma conexão TLS para o cliente de e-mail.
O cliente envia seu certificado para o servidor.
O servidor verifica o certificado e permite que o cliente retransmita se o certificado estiver entre aqueles que o servidor reconhece.

Redes privadas virtuais (VPNs) dão aos clientes acesso a um servidor de e-mail configurando uma rede virtual segura em execução na Internet regular. Em uma VPN, os administradores têm controle sobre endereços IP, então você pode usar o relaying com base no endereço IP. Estas são as etapas básicas para usar uma VPN:

O computador do cliente de e-mail se conecta a uma VPN.
O servidor SMTP permite que o cliente faça o relay com base no endereço IP do cliente na rede virtual.

SASL - Simple Authentication and Security Layer

O Postfix implementa a autenticação SMTP com a ajuda do SASL (Simple Authentication and Security Layer). O SASL é uma estrutura de autenticação descrita na RFC 2222, e entender como ele funciona é essencial para entender a autenticação SMTP como um todo. Existem várias implementações SASL, e o Postfix usa as bibliotecas Cyrus-SASL derivadas da implementação SASL original no Projeto Cyrus. O Projeto Cyrus é o nome do projeto da Carnegie Mellon University para construir um novo sistema de correio do campus.

O SASL consiste em três camadas que você deve configurar: a interface de autenticação, o mecanismo e o método.

A camada que lida com as conexões de rede e o início da autenticação. No caso do Postfix, isso seria o daemon smtpd que escuta conexões de entrada.
Um cliente se conecta e inicia a autenticação nestas quatro subetapas:

O cliente se conecta ao servidor e escolhe um mecanismo de autenticação SMTP AUTH.
O cliente prepara suas credenciais de acordo com o mecanismo escolhido.
O cliente informa ao servidor qual mecanismo ele escolheu.
O cliente envia suas credenciais para o servidor.

O servidor (ou o daemon do servidor de e-mail) armazena informações sobre o mecanismo de autenticação escolhido e as credenciais recebidas.
O servidor passa as informações sobre o mecanismo e as credenciais para um driver de mecanismo. O driver de mecanismo encaminha as informações para o serviço de verificação de senha.
O serviço de verificação de senha acessa um backend de autenticação, como /etc/shadow ou um banco de dados LDAP, e tenta corresponder as credenciais fornecidas com as entradas armazenadas.
O serviço de verificação de senha entrega o resultado do backend para o smtpd.
O smtpd toma uma ação com base no resultado. Por exemplo, ele pode deixar usuários autenticados retransmitirem e-mails.

Interface de autenticação

A interface de autenticação é um componente crucial para informar ao cliente que a autenticação está disponível e quais mecanismos podem ser usados para autenticar. No entanto, o SASL (Simple Authentication and Security Layer) não define uma interface de autenticação específica. Em vez disso, ele deixa para cada serviço e protocolo específico (como LDAP ou SMTP) integrar e comunicar a capacidade de autenticação ao cliente.

Cada serviço que requer autenticação tem seu próprio método para informar ao cliente sobre os mecanismos de autenticação disponíveis. Por exemplo, enquanto LDAP e SMTP podem ambos exigir autenticação, seus protocolos de comunicação são diferentes, e a forma como a autenticação é anunciada ao cliente varia conforme o serviço. Para servidores de e-mail, o processo de autenticação é integrado ao diálogo SMTP. O protocolo ESMTP (Extended SMTP) permite que a autenticação seja oferecida como um recurso adicional durante a comunicação entre o cliente e o servidor de e-mail.

Quando um cliente de e-mail se conecta a um servidor SMTP, ele pode verificar se a autenticação SMTP está disponível enviando o comando EHLO. A resposta do servidor incluirá uma lista de recursos suportados, e se a autenticação estiver disponível, a lista incluirá o comando AUTH. Isso indica que o servidor suporta a autenticação SMTP e está preparado para processar solicitações de autenticação usando vários mecanismos suportados. Para verificar se um servidor de e-mail oferece suporte à autenticação SMTP, siga estes passos:

Terminal

# Abra conexão na porta 25 do servidor:
$ telnet mail.example.com 25
220 mail.wlf.eti.br ESMTP Postfix

# Agora se apresente:
EHLO mail.test.com.br

# Se der tuco certo, o servidor vai responder com os métodos de autenticação que ele aceita:
250-mail.example.com
250-PIPELINING
250-SIZE 28871600
250-ETRN
250-STARTTLS
250-AUTH PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250-SMTPUTF8
250 CHUNKING

# Para sair envie:
QUIT

Mecanismos de Autenticação SMTP

Os mecanismos de autenticação SMTP, como PLAIN e LOGIN, definem a estratégia de verificação utilizada durante o processo de autenticação. O Cyrus SASL oferece uma ampla gama de mecanismos SASL, cada um com diferentes métodos de transmissão de credenciais e níveis de segurança. Alguns mecanismos são não padrão e foram desenvolvidos para clientes específicos. Não é necessário usar todos os mecanismos disponíveis. O Postfix pode ser configurado para oferecer apenas um conjunto limitado de mecanismos SASL fornecidos pelo Cyrus SASL.

Eu recomendo que você sempre use PLAIN, LOGIN e CRAM-MD5. Eles são amplamente suportados e adequados para a maioria dos clientes de e-mail. Esses mecanismos são recomendados para ambientes que precisam suportar clientes Windows, Mac OS e Unix, garantindo ampla compatibilidade e segurança adequada. Vejamos um resumo de cada mecanismo que podemos usar.

ANONYMOUS
Permite acesso anônimo aos serviços de e-mail. O cliente de e-mail precisa enviar qualquer string ao servidor, e o servidor permitirá que o cliente faça o relay de mensagens. Não use o mecanismo ANONYMOUS com o Postfix, a menos que você queira que seu servidor de e-mail se torne um relay aberto. Spammers sabem como abusar deste mecanismo.
CRAM-MD5 e DIGEST-MD5
Ambos são mecanismos de "segredo compartilhado". O CRAM-MD5 usa um desafio baseado no segredo compartilhado (geralmente uma senha), e o cliente responde provando que conhece o segredo. Já DIGEST-MD5 é uma versão mais avançada do CRAM-MD5, oferecendo um método de autenticação mais seguro e complexo. Mais seguro do que enviar uma senha não criptografada pela rede, mas o servidor ainda precisa armazenar o segredo compartilhado.
EXTERNAL
Permite que credenciais TLS/SSL sejam usadas para autenticação SASL. Especificamente, permite extrair algum tipo de nome de usuário do certificado usado durante a negociação TLS/SSL. Utilizado para situações onde as credenciais são baseadas em certificados TLS/SSL.
GSSAPI e KERBEROS_V4
Utilizam o sistema de autenticação Kerberos. KERBEROS_V4 é compatível com implementações de Kerberos v4, enquanto GSSAPI é compatível com Kerberos v5 (testado contra MIT e Heimdal Kerberos v5). Não requer um banco de dados de senhas, aproveitando a infraestrutura do Kerberos para autenticação.
OTP (One-Time Pad)
Semelhante ao CRAM-MD5 e DIGEST-MD5, utiliza um segredo compartilhado e um mecanismo de desafio/resposta. A diferença é que OTP usa uma sequência de senhas de uso único para prevenir ataques de replay, eliminando a necessidade de armazenar segredos no servidor. É considerado mais seguro porque os segredos são gerados e utilizados apenas uma vez, evitando o armazenamento de segredos sensíveis.
PLAIN e LOGIN
Transmite credenciais em texto simples codificado em base64. O PLAIN é simples e amplamente suportado, mas os strings base64 podem ser facilmente decodificados. LOGIN é semelhante ao PLAIN, mas é usado para clientes de e-mail que não seguem totalmente o RFC. O fato de que as credenciais são enviadas em texto simples cria um risco de segurança. Qualquer pessoa que execute um sniffer de rede pode ler as credenciais. Para mitigar esse problema, recomenda-se usar TLS em combinação com a autenticação SMTP em texto simples. Isso garante que o Postfix ofereça mecanismos de texto simples somente após uma sessão TLS ser estabelecida.

Instalando o Cyrus SASL

Para usar o Cyrus SASL, podemos compilar o código fonte ou instalar os pacotes sasl2-bin e libsasl2-2.

Serviços de Verificação de Senha

Os métodos de autenticação, também conhecidos como serviços de verificação de senha, são responsáveis por gerenciar os mecanismos de autenticação e pela comunicação entre a aplicação que oferece a autenticação SMTP e o backend que armazena as credenciais. O Cyrus SASL oferece dois serviços de verificação de senha: saslauthd e auxprop. Os dois serviços diferem nos mecanismos que podem oferecer e nos backends aos quais podem se conectar.

O aplicativo (como Postfix) deve escolher qual serviço de verificação de senha usar entre as opções disponíveis (saslauthd e auxprop). Essa escolha depende das necessidades específicas de autenticação e dos tipos de backends com os quais você deseja se conectar. Abaixo segue uma visão geral desses serviços:

saslauthd

O saslauthd é um daemon autônomo que pode ser executado com privilégios de superusuário. Ele pode se conectar a vários tipos de backends de autenticação, especialmente aqueles que exigem privilégios de superusuário, como o arquivo /etc/shadow. É limitado a mecanismos de autenticação em texto simples, como PLAIN e LOGIN. É adequado para ambientes onde a autenticação simples é suficiente e a conexão com backends que requerem privilégios elevados é necessária.

auxprop

O auxprop é um serviço de verificação de senha que serve como um "catchall" para vários plug-ins auxiliares. Cada plug-in é especializado em um tipo distinto de backend de autenticação, como sasldb2 (uma base de dados de senhas interna) e servidores SQL. Ele suporta uma ampla gama de mecanismos de autenticação, oferecendo maior versatilidade na escolha do backend de autenticação. É ideal para ambientes que requerem autenticação com uma variedade de backends e mecanismos, permitindo uma configuração mais personalizada e complexa.

Backends de autenticação

Os backends de autenticação são componentes cruciais no processo de autenticação SMTP, pois são responsáveis por verificar se as credenciais fornecidas pelo cliente correspondem às informações armazenadas. Cyrus SASL utiliza esses backends para confirmar a validade das credenciais e garantir que apenas usuários autorizados possam acessar os serviços. Aqui estão os principais backends de autenticação suportados pelo Cyrus SASL:

IMAP
Um servidor IMAP pode ser configurado para verificar credenciais. É ideal para ambientes que já utilizam um servidor IMAP para gerenciamento de e-mails e preferem integrar a autenticação com esse servidor.
Kerberos
O Cyrus SASL pode verificar tickets do Kerberos, um sistema de autenticação de rede robusto e seguro. É utilizado em ambientes que já utilizam Kerberos para autenticação centralizada e desejam integrar essa autenticação com o serviço SMTP.
LDAP (OpenLDAP)
O Cyrus SASL pode ler credenciais de um servidor OpenLDAP. É bastante adequado para organizações que utilizam um servidor LDAP para gerenciar informações de autenticação e diretórios de usuários.
PAM (Pluggable Authentication Modules)
O Cyrus SASL pode ler credenciais de módulos PAM disponíveis no sistema. É muito flexível e pode ser usado com diversos módulos PAM para autenticação, incluindo autenticação baseada em banco de dados ou métodos personalizados.
passwd/shadow
O Cyrus SASL pode acessar os bancos de dados de usuários do sistema, como /etc/passwd e /etc/shadow. É adequado para sistemas que utilizam autenticação local baseada em arquivos de sistema tradicionais.
sasldb2
É um banco de dados de usuários interno do Cyrus SASL chamado sasldb2, ele é necessário para o servidor IMAP Cyrus, mas também pode ser utilizado apenas para autenticação SMTP. É ideal para sistemas que preferem usar um banco de dados interno específico do SASL para armazenar credenciais.
SQL
O Cyrus SASL também pode acessar dados de usuários em servidores SQL. Atualmente, suporta MySQL e PostgreSQL.

Configuração do SASL para Aplicações

Toda aplicação que usa SASL precisa especificar como deve interagir com a biblioteca SASL. Cada aplicação pode ter seu próprio arquivo de configuração SASL, além de haver um arquivo de configuração global. Isso permite que você configure o SASL de forma específica para diferentes serviços rodando no mesmo servidor.

No Postfix, o serviço que implementa a autenticação SASL é o smtpd (o daemon que recebe emails), então o arquivo de configuração associado é tipicamente chamado de smtpd.conf. Este arquivo define como o Postfix deve interagir com a biblioteca SASL para autenticação. O local onde o arquivo smtpd.conf deve ser colocado pode variar dependendo do sistema operacional e da distribuição Linux que você está utilizando. Em geral, os locais comuns são:

Debian/Ubuntu:
- /etc/postfix/sasl/smtpd.conf
Red Hat/CentOS/Fedora:
- /etc/sasl2/smtpd.conf
Outros Locais Possíveis:
- /usr/lib/sasl2/smtpd.conf
- /usr/local/lib/sasl2/smtpd.conf

Caso o arquivo não exista é necessário criar ele:

Terminal

# Crie o arquivo:
$ sudo touch /etc/postfix/sasl/smtpd.conf

# Corrija as permissões:
$ sudo chmod 644 /etc/postfix/sasl/smtpd.conf

Agora já podemos configurar como o Postfix vai usar a biblioteca do SASL.

log_level
Define o nível de log do Cyrus SASL. Os valores são:

0: Nenhum log de depuração.
1: Erros são registrados.
2: Erros e mensagens de aviso são registrados.
3: Erros, mensagens de aviso e algumas mensagens informativas são registradas.
4: Mensagens detalhadas de depuração, incluindo erros, avisos e informações, são registradas.
5: Máximo de detalhe nas mensagens de log, incluindo todas as informações possíveis sobre o processo de autenticação.
pwcheck_method
É utilizado para definir qual método de verificação de senha será usado durante o processo de autenticação. Esse parâmetro é crucial, pois determina como as credenciais fornecidas pelo cliente serão verificadas contra os dados de autenticação armazenados. Os valores comuns são:

auxprop: Usado quando você deseja utilizar plug-ins auxiliares (como sasldb2, SQL, etc.) para verificar as senhas. Este método é adequado para armazenamentos de senha embutidos ou personalizados.

saslauthd: Aponta para o uso do daemon saslauthd como o método de verificação. saslauthd pode se conectar a diversos backends, como /etc/shadow, LDAP, PAM, entre outros, e é frequentemente utilizado para mecanismos de autenticação baseados em texto simples, como PLAIN e LOGIN.

passwd: Permite que o Cyrus SASL verifique as senhas diretamente nos arquivos de sistema /etc/passwd ou /etc/shadow.

Atenção ao usdo do saslauthd
Quando se usa o saslauthd com LDAP, ele pode ser configurado para consultar diretamente o banco de dados LDAP para autenticar usuários. Isso é necessário se você estiver usando métodos de autenticação que requerem o armazenamento de senhas criptografadas ou se o backend LDAP não suporta métodos de autenticação com senhas em texto claro.

O plugin ldapdb do auxprop não é compatível com senhas criptografadas. Se você precisa armazenar e verificar senhas criptografadas, o saslauthd pode ser configurado para consultar diretamente o LDAP, como especificado no saslauthd.conf.

Métodos de autenticação que requerem acesso a senhas em texto claro, como CRAM-MD5 e DIGEST-MD5, não podem ser usados quando as senhas são armazenadas em formato criptografado. Nesse caso, o saslauthd consulta diretamente o LDAP para validar as credenciais.
mech_list
Define a lista de mecanismos de autenticação (SASL mechanisms) que o servidor oferece aos clientes durante o processo de autenticação SMTP. As opções possíveis já foram explicadas aqui.

Configurando o saslauthd

O arquivo /etc/default/saslauthd controla a inicialização do serviço e outros parâmetros importantes. Edite esse arquivo para ajustar as opções globalmente. Tanto na configuração Global quanto por serviço, temos que adicionar START=yes nesse arquivo para iniciar junto com o sistema.

A opção MECHANISMS define o mecanismo de autenticação que o saslauthd deve usar. As opções foram explicadas aqui. A opção OPTIONS permite definir opções adicionais. Por exemplo, o caminho do socket.

/etc/default/saslauthd
OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd"

# -c: Permite cache de credenciais.
# -m: Especifica o caminho do diretório do socket onde o saslauthd cria seus arquivos de comunicação.

Cuidado

É necessário que o socket do saslauthd seja criado dentro do diretório do Postfix para que o Postfix possa se comunicar corretamente com o saslauthd.

Agora que definido para trabalhar com o postfix, temos que corrigir as permissões do diretório que especificamos:

Terminal

$ sudo dpkg-statoverride --force --update --add root sasl 755 /var/spool/postfix/var/run/saslauthd

dica

Algumas distribuições exigem que o usuário postfix seja membro de um grupo especial, por exemplo, sasl, caso contrário ele não poderá acessar o diretório de sockets saslauthd.

Configurando o saslauthd com o PAM

Vamos configurar o saslauthd para usar o PAM como Backends de autenticação. Primeiro de tudo, certifique-se de instalar os pacotes necessários:

Terminal

$ sudo apt install -y libsasl2-2 sasl2-bin

Agora garanta que você tem esses mesmos dados nos arquivos de configuração:

/etc/postfix/sasl/smtpd.conf

pwcheck_method: saslauthd
mech_list: LOGIN PLAIN

/etc/default/saslauthd
MECHANISMS="pam"
OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd"
START=yes

Restarte o serviço e teste:

Terminal

# Reinicie o serviço:
$ sudo systemctl restart saslauthd

# Para testar:
testsaslauthd -u USERNAME -p SENHA -s smtp -f /var/spool/postfix/var/run/saslauthd/mux

ATENÇÂO

O Postfix, por si só, não consegue autenticar usuários; ele depende de uma biblioteca externa para realizar essa tarefa. O saslauthd é o daemon que faz a autenticação, e ele pode se conectar a diferentes backends de autenticação, como PAM, LDAP, ou até mesmo os arquivos /etc/passwd e /etc/shadow.

O arquivo /etc/postfix/sasl/smtpd.conf foi usado para configurar como o Postfix deve se comunicar com o saslauthd. Nele, nós definimos o método de verificação de senha (pwcheck_method), e os mecanismos de autenticação que serão oferecidos (mech_list), basicamente.

Além disso, o saslauthd precisava ser configurado para usar o backend correto para a validação das credenciais, e é por isso que configuramos OPTIONS, MECHANISMS e START em /etc/default/saslauthd. A opção -m foi usada para apontar o caminho do diretório onde o socket do saslauthd será criado, garantindo que o Postfix possa se comunicar com ele.

Depois de configurar o /etc/postfix/sasl/smtpd.conf e o /etc/default/saslauthd, nós ainda precisamos ajustar as configurações do Postfix para que ele utilize a autenticação SASL, mas não faremos isso ainda.

Configurando o saslauthd com o LDAP

Vamos configurar o saslauthd para usar o LDAP como Backends de autenticação. Primeiro de tudo, certifique-se de instalar os pacotes necessários:

Terminal

$ sudo apt install -y libsasl2-2 sasl2-bin

Agora garanta que você tem esses mesmos dados nos arquivos de configuração:

/etc/default/saslauthd
MECHANISMS="ldap"
OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd"
START=yes

A configuração do LDAP para validação de usuários em um sistema de e-mail pode variar bastante dependendo de vários fatores. O LDAP pode usar diferentes schemas para armazenar e organizar informações. É importante conhecer o schema usado para garantir que as consultas sejam feitas corretamente. A estrutura da árvore LDAP (DN, OU, etc.) determina onde as informações de usuário estão localizadas. É necessário saber o DN base (base DN) e como as entradas estão organizadas.

Pelo fato de o auxprop não ser compatível com senhas criptografadas teremos que usar o saslauthd. Como o mesmo precisará acessar senha criptografadas, será necessário configurar o arquivo saslauthd.conf para que o saslauthd saiba como se conectar no LDAP e obter os dados para validação. Isso já implica que o exemplo usado aqui trabalha com LDAP e senhas de usuários criptografadas. O exemplo abaixo é um modelo de configuração que o saslauthd usa para se comunicar com o LDAP. Para um LDAP com outros métodos diferentes do que será mostrado mais adiante, você deve adaptar o ldap_filter além de outras opções para refletir seu ambiente.

/etc/saslauthd.conf
ldap_servers: ldap://127.0.0.1
ldap_bind_dn: cn=admin,dc=example,dc=com,dc=br
ldap_bind_pw: SENHA
ldap_timeout: 10
ldap_time_limit: 10
ldap_scope: sub
ldap_search_base: ou=accounts,dc=example,dc=com,dc=br
ldap_auth_method: bind
ldap_filter: (&(objectClass=inetLocalMailRecipient)(mailLocalAddress=%u))
ldap_debug: 0
ldap_verbose: off
ldap_ssl: no
ldap_starttls: no
ldap_referrals: yes
ldap_deref: never
ldap_restart: yes

Abaixo segue um resumo das opções usadas acima.

Opção	Descrição	Uso
ldap_servers	Define o URI do servidor LDAP.	Indica o endereço e protocolo de conexão com o servidor LDAP.
ldap_bind_dn	DN (Distinguished Name) do usuário para autenticação no LDAP.	O `saslauthd` usa este DN para se autenticar ao LDAP.
ldap_bind_pw	Senha para o DN especificado em `ldap_bind_dn`.	Fornece a senha para autenticação no LDAP.
ldap_timeout	Tempo limite para a conexão com o servidor LDAP, em segundos.	Define quanto tempo o `saslauthd` esperará pela conexão antes de considerar a falha.
ldap_time_limit	Tempo máximo para uma busca LDAP, em segundos.	Define o tempo máximo para completar uma busca antes de interromper.
ldap_scope	Escopo da busca LDAP (base, one, sub).	`sub` indica que a busca irá considerar toda a abaixo da base especificada.
ldap_search_base	Base DN a partir da qual a busca LDAP será realizada.	Define o ponto inicial para as buscas na árvore LDAP.
ldap_auth_method	Método de autenticação usado para validar credenciais LDAP.	`bind` indica que o `saslauthd` usará o método de autenticação "bind".
ldap_filter	Filtro LDAP usado para buscar o usuário.	Especifica como os usuários serão filtrados na árvore LDAP.
ldap_debug	Nível de depuração para o `saslauthd`.	`0` desativa a depuração; valores maiores para mais informações de depuração.
ldap_verbose	Define se mensagens detalhadas de depuração devem ser exibidas.	`off` desativa mensagens detalhadas de depuração.
ldap_ssl	Especifica se a conexão com o LDAP deve usar SSL.	`no` indica que SSL não será usado; para maior segurança, deve ser `yes`.
ldap_starttls	Define se o `saslauthd` deve usar StartTLS para criptografar a conexão LDAP.	`no` significa que StartTLS não será usado; para maior segurança, deve ser `yes`.
ldap_referrals	Define se o `saslauthd` deve seguir referências LDAP.	`yes` permite seguir referências LDAP para localizar usuários caso a busca inicial falhe.
ldap_deref	Define quando o `saslauthd` deve desreferenciar entradas LDAP.	`never` significa que desreferenciações não serão feitas.
ldap_restart	Define se o `saslauthd` deve reiniciar automaticamente após uma falha.	`yes` permite reinício automático, ajudando a manter o serviço disponível após falhas.

ATENÇÂO

O arquivo /etc/postfix/sasl/smtpd.conf não foi usado porque agora é o Dovecot quem fará a autenticação do cliente. Observe que isso informava o SASL Cyrus para ser o plugin de autenticação, mas o Postfix ainda precisa usar a configuração com LDAP para validar os clientes ao receberem email por exemplo.

Depois nós configuramos o saslauthd para que ele consiga se conectar ao nosso servidor LDAP usando o arquivo /etc/saslauthd.conf.

Depois de configurar o /etc/default/saslauthd e /etc/saslauthd.conf, nós ainda precisamos ajustar as configurações do Postfix para que ele utilize a autenticação SASL e principalmente fazer com que o Postifx trabalhe adequadamente com LDAP. Isso é necessário pois o Postfix vai precisar consultar o LDAP para resolver endereços de e-mail, já que os endereços dos destinatários vão ficar armazenados em um diretório LDAP.

Note também que essa configuração LDAP nos Postfix não obtem senha, isso acontece porque vamos usar o Dovecot como MDA e ele quem cuidará da autenticação dos usuários.

Configurando o Postfix para usar autenticação

Por padrão, o SMTP do Postfix usa a implementação Cyrus SASL como já vimos anteriormente, acontece que ainda podemos usar a implementação Dovecot SASL. A escolha entre essas duas implementações pode depender de preferências específicas, requisitos de segurança ou integrações desejadas com outros serviços.

Cyrus SASL
Configurado através dos arquivos /etc/postfix/sasl/smtpd.conf e /etc/default/saslauthd. Suporta uma variedade de mecanismos de autenticação e backends. É uma solução robusta, mas pode exigir mais configuração, especialmente em relação à integração com LDAP e outras fontes de autenticação.
Dovecot SASL
Configurado diretamente no Dovecot, geralmente em arquivos como /etc/dovecot/conf.d/10-auth.conf e /etc/dovecot/conf.d/10-master.conf. Pode ser mais fácil de configurar se você já está utilizando Dovecot para a entrega de e-mails e autenticação.

Postfix com Cyrus SASL

O primeiro passo para configurar o Cyrus SASL é determinar o nome e o local de um arquivo de configuração que descreve como o servidor SMTP do Postfix usará a estrutura SASL, isso já foi realizado mas para fixar melhor os conhecimentos, faremos novamente. Configure os arquivos abaixo:

/etc/postfix/sasl/smtpd.conf

pwcheck_method: saslauthd
mech_list: LOGIN PLAIN

/etc/default/saslauthd
MECHANISMS="pam"
OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd"
START=yes

/etc/postfix/main.cf
# Habilita a autenticação SASL no servidor SMTP.
smtpd_sasl_auth_enable = yes

# Desative a autenticação anonima:
smtpd_sasl_security_options = noanonymous

# Define o caminho para o arquivo de configuração do SASL. 
smtpd_sasl_path = smtpd

# Aplica restrições ao endereço do destinatário especificado no comando RCPT TO. Basicamente regras de bloqueio de spam.
smtpd_recipient_restrictions = 
    permit_mynetworks
    permit_sasl_authenticated
    reject_unauth_destination
    reject_non_fqdn_recipient
    reject_unknown_recipient_domain
    reject_unauth_pipelining
    reject_unverified_recipient

# Define restrições aplicadas após o comando DATA, que precede o envio do corpo da mensagem.
smtpd_data_restrictions =
   permit_mynetworks
   permit_sasl_authenticated
   reject_multi_recipient_bounce
   reject_unauth_pipelining

# Aplica restrições ao endereço do remetente especificado no comando MAIL FROM.
smtpd_sender_restrictions =
   permit_mynetworks
   permit_sasl_authenticated
   reject_non_fqdn_sender
   reject_unknown_sender_domain
   reject_unauth_pipelining

# Aplica regras de retransmissão (relay) de emails:
smtpd_relay_restrictions =
   permit_mynetworks
   permit_sasl_authenticated
   reject_unauth_destination

# Define restrições baseadas no cliente que está tentando se conectar ao servidor SMTP.
smtpd_client_restrictions =
   permit_mynetworks
   permit_sasl_authenticated
   reject_unknown_reverse_client_hostname
   reject_unauth_pipelining

# Controla as restrições baseadas no comando HELO/EHLO.
smtpd_helo_restrictions =
   permit_mynetworks
   permit_sasl_authenticated
   reject_invalid_helo_hostname
   reject_non_fqdn_helo_hostname
   reject_unauth_pipelining

Agora vamos configurar o serviço de submissão (submission), para permitir que clientes de e-mail se conectem ao servidor SMTP para enviar/receber e-mails estando autenticados. O serviço de submissão geralmente escuta na porta 587 e é projetado para permitir que clientes e dispositivos enviem e-mails de maneira segura e autenticada. É diferente do serviço SMTP padrão que escuta na porta 25, que é frequentemente usado para comunicação entre servidores de e-mail.

/etc/postfix/master.cf
submission inet n       -       -       -       -       smtpd
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o tls_preempt_cipherlist=yes
  -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
  -o milter_macro_daemon_name=ORIGINATING

Postfix com Dovecot SASL

Dovecot é um servidor POP/IMAP que tem sua própria configuração para autenticar clientes POP/IMAP. Quando o servidor SMTP Postfix usa Dovecot SASL, ele reutiliza partes dessa configuração. Não vou mostrar agora como configurar a fundo o Dovecot, apenas o Postfix, mas numa seção mais a frente mostrarei como fazer a configuração completa.

Configure os arquivos abaixo:

/etc/postfix/sasl/smtpd.conf

pwcheck_method: saslauthd
mech_list: LOGIN PLAIN

/etc/default/saslauthd
MECHANISMS="pam"
OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd"
START=yes

/etc/postfix/main.cf
# Habilita a autenticação SASL no servidor SMTP.
smtpd_sasl_auth_enable = yes

# Desative a autenticação anonima:
smtpd_sasl_security_options = noanonymous

# Configura o 'Dovecot SASL' como método de autenticação e autorização no Servidor SMTP Postfix.
smtpd_sasl_type = dovecot

# Configura a comunicação do Postfix com o Dovecot usando sockets UNIX.
smtpd_sasl_path = private/auth

# Aplica restrições ao endereço do destinatário especificado no comando RCPT TO. Basicamente regras de bloqueio de spam.
smtpd_recipient_restrictions = 
    permit_mynetworks
    permit_sasl_authenticated
    reject_unauth_destination
    reject_non_fqdn_recipient
    reject_unknown_recipient_domain
    reject_unauth_pipelining
    reject_unverified_recipient

# Define restrições aplicadas após o comando DATA, que precede o envio do corpo da mensagem.
smtpd_data_restrictions =
   permit_mynetworks
   permit_sasl_authenticated
   reject_multi_recipient_bounce
   reject_unauth_pipelining

# Aplica restrições ao endereço do remetente especificado no comando MAIL FROM.
smtpd_sender_restrictions =
   permit_mynetworks
   permit_sasl_authenticated
   reject_non_fqdn_sender
   reject_unknown_sender_domain
   reject_unauth_pipelining

# Aplica regras de retransmissão (relay) de emails:
smtpd_relay_restrictions =
   permit_mynetworks
   permit_sasl_authenticated
   reject_unauth_destination

# Define restrições baseadas no cliente que está tentando se conectar ao servidor SMTP.
smtpd_client_restrictions =
   permit_mynetworks
   permit_sasl_authenticated
   reject_unknown_reverse_client_hostname
   reject_unauth_pipelining

# Controla as restrições baseadas no comando HELO/EHLO.
smtpd_helo_restrictions =
   permit_mynetworks
   permit_sasl_authenticated
   reject_invalid_helo_hostname
   reject_non_fqdn_helo_hostname
   reject_unauth_pipelining

/etc/postfix/master.cf
submission inet n       -       -       -       -       smtpd
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o tls_preempt_cipherlist=yes
  -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
  -o milter_macro_daemon_name=ORIGINATING

O diagrama abaixo ilustra como é a comunicação entre os serviços durante a autenticação do cliente.

postfix dovecot ldap

Conexão do MUA ao Postfix
O MUA (Mail User Agent) do cliente se conecta ao Postfix na porta 587 (submission). O cliente envia o nome de usuário, senha e outras informações necessárias para autenticação e envio de email.
Autenticação com Dovecot via SASL
O Postfix utiliza o Dovecot para autenticação, pois a configuração smtpd_sasl_type = dovecot foi definida. A comunicação entre Postfix e Dovecot ocorre via sockets, conforme especificado em smtpd_sasl_path = private/auth.
Dovecot consulta o LDAP
O Dovecot, configurado para usar LDAP (driver = ldap), consulta o servidor LDAP para verificar as credenciais do usuário. O arquivo de configuração /etc/dovecot/dovecot-ldap.conf.ext é utilizado para determinar como o Dovecot se conecta ao LDAP e como as consultas são realizadas. Se as credenciais do usuário forem válidas, a autenticação é bem-sucedida.
Sincronização de emails via IMAP
Após a autenticação bem-sucedida, o Dovecot sincroniza os emails do cliente no MUA usando a porta 993 (IMAP sobre SSL/TLS) do servidor. O MUA pode agora enviar e receber emails através do Postfix e acessar a caixa de correio usando o Dovecot.

Introdução do TLS

O TLS (Transport Layer Security) é um protocolo que oferece comunicação criptografada e identificação segura em uma rede, usado principalmente em servidores de e-mail para proteger as transmissões de SMTP e a autenticação SASL. O TLS é uma evolução do SSL (Secure Sockets Layer). mas evoluiu para se tornar mais robusto e seguro. O TLS criptografa os dados transmitidos pela rede, protegendo-os contra interceptação e adulteração.

Vou deixar um aviso que está na documentação do Postfix para que fiquem cientes: Ativar o TLS no Postfix adiciona complexidade. Especificamente, a integração do TLS exige a incorporação de grandes quantidades de código da OpenSSL, o que aumenta o risco de bugs, já que cada nova linha de código introduz potenciais vulnerabilidades.

O Problema que o TLS Resolve

O SMTP, como foi originalmente projetado, não oferece proteção contra intrusos que possam estar monitorando o tráfego de rede. Sem o uso de TLS, o conteúdo de mensagens confidenciais e senhas é transferido em pacotes TCP em texto simples. Isso significa que qualquer pessoa com acesso ao caminho desse fluxo de dados pode capturar esses pacotes e reconstruir a comunicação, obtendo acesso às informações sensíveis.

O TLS corrige essa vulnerabilidade criptografando a comunicação entre dois hosts antes que qualquer dado confidencial seja transmitido pela rede. No Postfix, o TLS pode ser configurado não apenas para proteger o tráfego de dados, mas também para permitir a retransmissão segura com base em um sistema de certificados. Isso garante que as mensagens e as credenciais sejam transmitidas de forma segura, protegendo-as contra interceptação e acesso não autorizado.

Conceitos Básicos de TLS

A comunicação padrão entre cliente e servidor SMTP não é criptografada, o cliente simplesmente estabelece uma conexão TCP e começa a transmitir dados. A menos que o conteúdo tenha sido criptografado por outro sistema, ele é transportado em texto simples, legível por qualquer pessoa capaz de interceptar o fluxo de dados. Um invasor poderia facilmente visualizar o conteúdo e, se tivesse controle de um roteador, possivelmente alterá-lo. Esses ataques são impossíveis quando o cliente e o servidor utilizam TLS, porque esse sistema oferece três proteções essenciais:

Privacidade
A comunicação entre o cliente e o servidor é encapsulada dentro de uma sessão criptografada. Um terceiro, sem acesso ao cliente e ao servidor, não pode decifrar os dados trocados.
Integridade
Mesmo que um ataque man-in-the-middle seja possível, ambas as partes podem detectar imediatamente qualquer alteração no conteúdo.
Prova de Autenticidade
O cliente e o servidor podem trocar certificados que são validados por uma autoridade certificadora confiável (CA), provando a autenticidade dos hosts envolvidos. Um certificado contém informações como o FQDN do host. Ataques como spoofing de DNS, por exemplo, seriam detectados antes que os dados fossem enviados.

Embora o TLS seja uma ferramenta poderosa para proteger a transmissão de e-mails, é importante entender suas limitações. O TLS protege o conteúdo apenas durante o trânsito entre o cliente de e-mail e o servidor de envio. Uma vez que o servidor de e-mail recebe e armazena a mensagem, ela volta a estar em texto não criptografado. Além disso existem algumas considerações cruciais sobre o uso do TLS:

O TLS assegura a criptografia apenas na comunicação entre o cliente e o servidor de e-mail do remetente. No entanto, após a mensagem ser entregue ao servidor, ela é armazenada sem criptografia.
O servidor de e-mail pode precisar encaminhar a mensagem para outro servidor. Se algum dos servidores ao longo do caminho não suportar TLS, a mensagem poderá ser transmitida em texto simples, comprometendo sua segurança.
Mesmo que você imponha criptografia em seus servidores de e-mail, não há garantia de que a mensagem permanecerá criptografada ao deixar sua organização. Um servidor intermediário que não suporte TLS resultará na transmissão em texto não criptografado.
O TLS não garante proteção para e-mails que são rejeitados e retornados ao remetente como não entregues. O caminho de retorno pode diferir, e os servidores utilizados no retorno podem não oferecer a mesma proteção.

Para garantir a proteção total do conteúdo do e-mail, é essencial criptografar o conteúdo da mensagem (basicamente o body para ficar fácil de entender) antes de enviá-la. Ferramentas como S/MIME, PGP, e GnuPG oferecem soluções robustas para criptografia de conteúdo, garantindo que a mensagem permaneça segura mesmo fora do ambiente protegido pelo TLS.

Como o TLS Funciona

O TLS criptografa a comunicação entre exatamente dois hosts. O processo de uma sessão com TLS habilitado é exibido abaixo:

Um cliente se conecta a um servidor.
Os hosts iniciam a comunicação SMTP.
O servidor oferece TLS utilizando a palavra-chave STARTTLS dentro da comunicação SMTP.
Se o cliente for capaz de usar TLS, ele responde enviando o comando STARTTLS ao servidor.
O certificado público do servidor é assinado com a chave privada e enviado ao cliente.
O cliente verifica o certificado do servidor checando a assinatura da CA contra a assinatura pública da CA armazenada em seu próprio repositório de certificados raiz.
O cliente verifica o certificado do servidor comparando a string do Nome Comum (Common Name) do certificado com o nome de host DNS do servidor.
Cliente e servidor passam a se comunicar de forma criptografada.
Os hosts trocam dados de maneira segura.
A sessão é encerrada.

O Postfix integra o TLS através de vários componentes, cada um desempenhando um papel fundamental no estabelecimento e manutenção de conexões seguras. Abaixo está uma explicação dos principais componentes envolvidos:

smtpd(8)
Implementa o lado servidor do SMTP sobre TLS. Com ele as conexões SMTP recebidas são protegidas usando TLS, garantindo que os dados do e-mail sejam criptografados durante a transmissão.
smtp(8)
Implementa o lado cliente do SMTP (e LMTP) sobre TLS. Gerencia conexões SMTP de saída que exigem criptografia TLS, protegendo os dados enviados pelo servidor Postfix.
tlsmgr(8)
Gerencia os aspectos criptográficos do TLS no Postfix, como:
- Mantém o Gerador de Números Aleatórios Pseudo-Random (PRNG), essencial para gerar as chaves de criptografia usadas nas sessões TLS.
- Gerencia os arquivos de cache de chaves de sessão TLS, que armazenam informações sobre sessões TLS em andamento e recentes para melhorar o desempenho e a segurança.
tlsproxy(8)
Funciona de forma semelhante ao smtpd(8), mas é utilizado em casos específicos onde um proxy é necessário para lidar com conexões TLS.
postscreen(8)
Usa TLS para filtrar conexões SMTP recebidas, reduzindo a carga no smtpd(8) ao filtrar o tráfego indesejado antes que ele chegue ao servidor principal.

dica

Podemos ver se o Postfix tem suporte ao TLS usando o comando abaixo, caso não tenha, será necessário recompilar o sistema com o suporte a TLS.

Terminal

$ sudo postconf -d | grep tls

Certificados

Os certificados são fundamentais para garantir que apenas os hosts designados possam se comunicar de forma segura. Quando cada host pode verificar o certificado do outro, eles concordam em criptografar a sessão. Se a verificação falhar, o processo de criptografia é interrompido e avisos são emitidos, pois a base para a confiança (ou autenticidade) está comprometida.

Ao criar um certificado, seu sistema gera dois arquivos no disco: um contendo a chave pública e outro com a chave privada. O host remetente usa sua chave privada para criptografar dados, enquanto o host receptor utiliza a chave pública correspondente para descriptografar esses dados e verificar a autenticidade do remetente. Além disso, a chave pública pode ser assinada por uma Autoridade Certificadora (CA), que garante a validade do certificado. Quando um host receptor precisa verificar um certificado, ele não consulta diretamente a CA a cada vez, o que economiza tráfego e evita possíveis manipulações externas.

Em vez disso, o receptor compara localmente a assinatura da chave pública da CA com uma soma de verificação do certificado. A CA calcula e adiciona essa soma de verificação ao certificado durante o processo de assinatura. Se o certificado for alterado de qualquer forma, a soma de verificação será alterada, tornando o certificado inválido e imediatamente detectado pelo mecanismo TLS como manipulado. Para que a confiança seja estabelecida entre um cliente e um servidor, é necessário cumprir diferentes requisitos:

Um cliente de e-mail que verifica a autenticidade de um certificado do servidor deve ter acesso à chave pública da CA. Alguém deve importar essa chave para o repositório de certificados do sistema operacional do cliente, onde o cliente de e-mail e outras aplicações possam acessá-la. A maioria dos sistemas operacionais modernos já inclui um repositório de certificados de Autoridades Certificadoras (CAs) confiáveis. Esses repositórios contêm certificados de CAs amplamente reconhecidas e aceitas, permitindo que o cliente de e-mail e outras aplicações verifiquem a autenticidade dos certificados dos servidores.
Um servidor de e-mail que emite um certificado deve possuir chaves privada e pública válidas. As chaves públicas precisam ser assinadas por uma CA.

Existem várias autoridades certificadoras (CAs) que podem emitir certificados. Além das CAs oficiais, você também pode criar certificados autoassinados.

Uso Privado: Se o certificado for destinado apenas a uso interno, como em uma empresa ou em uma rede controlada por você, considerar a criação de sua própria autoridade certificadora pode ser uma opção viável. Neste caso, você assina o certificado do servidor com sua própria CA e distribui tanto o certificado raiz da sua CA quanto o certificado do servidor para seus clientes e servidores. Isso geralmente envolve menos esforço e custo, mas é importante notar que clientes e servidores fora da sua organização não confiarão automaticamente em certificados assinados por sua CA interna.
Uso Oficial: Para interações com usuários externos e servidores de e-mail fora do seu controle, é recomendável utilizar uma CA oficial. Estas CAs são amplamente reconhecidas e confiáveis.

Root Store

O parâmetro smtpd_tls_CAfile no Postfix é crucial para a configuração do TLS (Transport Layer Security) e determina o arquivo que contém os certificados de Autoridades Certificadoras (CAs) confiáveis. Esses certificados são usados para verificar a autenticidade dos certificados apresentados pelos clientes durante a negociação TLS. Durante a negociação TLS, o servidor Postfix usa o arquivo especificado para verificar se os certificados dos clientes foram assinados por uma CA confiável. Se o certificado do cliente for válido e assinado por uma CA presente no arquivo, a conexão TLS é estabelecida com segurança.

Para evitar que o Postfix adicione certificados de CA padrão fornecidos pelo sistema e confie apenas em certificados de terceiros, use o parâmetro tls_append_default_CA = no. Se o servidor de e-mail não está configurado para solicitar ou exigir certificados de cliente, você não precisa configurar o parâmetro smtpd_tls_CAfile para validação de certificados de clientes. Esse parâmetro é relevante principalmente quando o servidor espera autenticação baseada em certificados de clientes, onde o smtpd_tls_CAfile é usado para validar os certificados apresentados pelos clientes.

Preparando o Postfix para receber certificado

Independente de você planejar usar os certificados para smtp (cliente de e-mail) ou smtpd (servidor de e-mail), você deve copiar todos os certificados para o diretório onde o Postfix tenha acesso, uma forte recomendação é colocar em /etc/postfix/certs. Abaixo segue uma representação de como fazer isso.

Terminal

# Crie o diretório para os certificados:
$ sudo mkdir -p /etc/postfix/certs

# Copie os certificados para o diretório:
$ sudo cp cacert.pem /etc/postfix/certs/
$ sudo cp ../*.pem /etc/postfix/certs/

# Proteja a chave privada do servidor (`postfix_private_key.pem`) para que apenas o proprietário possa acessá-la:
$ cd /etc/postfix/certs
$ sudo chmod 600 postfix_private_key.pem

# Verifique as permissões dos arquivos:
$ ls -l /etc/postfix/certs/

A próxima etapa é configurar os caminhos para os arquivos que contêm seus certificados de servidor. Pelo menos, você deve fornecer a chave privada do servidor e o certificado do servidor assinado por uma autoridade certificadora. Essas configurações devem ser adicionadas ao arquivo main.cf do Postfix. Aqui está um exemplo de configuração, assumindo que os certificados estão localizados em /etc/postfix/certs como no exemplo acima:

/etc/postfix/main.cf
# Chave privada:
smtpd_tls_key_file = /etc/postfix/certs/postfix_private_key.pem

# Chave pública/certificado assinado por uma CA:
smtpd_tls_cert_file = /etc/postfix/certs/postfix_public_cert.pem

Essas configurações assumem que a chave privada e o certificado do servidor estão em arquivos separados. Caso você decida combinar a chave privada e o certificado em um único arquivo, você pode ajustar a configuração para refletir isso. Por exemplo, se você combinar ambos em um único arquivo, você pode usar:

"/etc/postfix/main.cf
smtpd_tls_cert_file = /etc/postfix/certs/postfix_combined_cert.pem

Nessa configuração, o arquivo combinado deve conter tanto a chave privada quanto o certificado do servidor.

Habilitando TLS no Postfix

No TLS do servidor, o Postfix atua como um servidor de e-mail (MTA), oferecendo TLS para clientes de e-mail. Você pode configurar o Postfix para criptografar a camada de transporte, ocultando toda a sessão de comunicação SMTP, para receber credenciais SMTP AUTH de texto simples com segurança ou para retransmitir e-mails para clientes com base nos certificados que os clientes apresentam. Tenha em mente que o Postfix não oferece STARTTLS para o utilitário de linha de comando sendmail.

Além das configurações que fizemos acima de adicionar o certificado e chave privada na configuração do Postfix, ainda temos que habilitar o uso do TLS, conectar o Postix num gerador de origem randomica e adicionar informação ao cabeçalho para rastreio futuro. Por padrão, o Postfix não vem com o TLS habilitado, precisamos então habilitar. Para habilitar TLS do lado do servidor, defina o parâmetro smtpd_use_tls:

"/etc/postfix/main.cf
smtpd_use_tls = yes

Após recarregar a configuração, o Postfix oferece STARTTLS para clientes de e-mail no diálogo SMTP para informá-los de que eles podem negociar uma sessão TLS.

Agora como uma prática que não pode faltar é configurar os logs do TLS. Para habilitar os logs do TLS no Postfix, você precisará configurar os parâmetros apropriados no arquivo main.cf. O parâmetro smtpd_tls_loglevel controla o nível de detalhe das informações de log sobre as sessões TLS. Os valores possíveis variam de 0 a 4, onde 0 desativa os logs TLS e 4 fornece o máximo de detalhes.

0: Nenhum log TLS.
1: Logs básicos, incluindo o início e o término das sessões TLS.
2: Logs detalhados sobre a negociação do handshake TLS.
3: Logs detalhados sobre a negociação das cifras e dos certificados.
4: Logs completos, incluindo mensagens e detalhes internos do TLS.

Normalmente o nível 1 é suficiente.

dica bonus

Certos clientes de e-mail, como Microsoft Outlook, só suportam mecanismos de segurança em texto simples, como PLAIN e LOGIN, o que pode expor nomes de usuário e senhas se transmitidos sem criptografia. Para proteger essas credenciais, configure o Postfix para oferecer SMTP AUTH apenas em conexões criptografadas (TLS) com smtpd_tls_auth_only = yes. Isso garante que as credenciais não sejam enviadas em texto simples em conexões não criptografadas, mas pode impedir o uso de alguns mecanismos seguros em sessões SMTP regulares.

Controlando mecanismos SASL em TLS

É uma boa escolha proibir mecanismos de texto simples em comunicação SMTP regular, ou seja, que não é criptografada, para isso usamos os parâmetros smtpd_sasl_tls_security_options e smtpd_sasl_security_options. O parâmetro smtpd_sasl_security_options define as opções de segurança para autenticação SASL em comunicações SMTP regulares (não criptografadas). Já o parâmetro smtpd_sasl_tls_security_options define as opções de segurança para autenticação SASL em sessões que utilizam TLS.

Duas configurações boas para smtpd_sasl_security_options são:

noanonymous
Impede autenticação anônima, ou seja, não permite que um cliente se autentique sem fornecer uma identidade.
noplaintext
Impede o uso de mecanismos de autenticação que transmitem credenciais em texto simples, como PLAIN ou LOGIN, em comunicações não criptografadas.

Já para smtpd_sasl_tls_security_options, a configuração é:

noanonymous
Impede autenticação anônima, mas permite o uso de mecanismos de texto simples dentro de uma sessão criptografada TLS, garantindo que as credenciais ainda sejam protegidas.

A combinação dos dois parâmetros permite que você exija segurança adicional para conexões não criptografadas, enquanto relaxa essas exigências para conexões criptografadas com TLS, onde o uso de mecanismos de texto simples é seguro. A configuração deve ficar assim:

"/etc/postfix/main.cf
smtpd_sasl_security_options = noanonymous, noplaintext
smtpd_sasl_tls_security_options = noanonymous

Recapitulando pois é importante entender essa configuração acima. Se você tiver que usar os mecanismos de texto simples, o cliente deve iniciar uma sessão TLS primeiro. A primeira regra proíbe mecanismos de autenticação anônimos e de texto simples em uma camada de transporte não criptografada, e a segunda permite mecanismos de texto simples ao falar com o servidor com TLS mas bloqueia acessos anônimos.

Observação, em alguns casos, aplicar apenas a configuração acima pode resultar em atrasos ou na impossibilidade de receber emails. Para isso, certifique-se de configurar igual abaixo. Mais para frente, as opções aqui descritas serão explicadas.

"/etc/postfix/main.cf
smtpd_sasl_security_options = noanonymous, noplaintext
smtpd_sasl_tls_security_options = noanonymous
tls_random_source = /dev/random
smtpd_tls_auth_only = yes

Forçando toda comunicação com TLS

O parâmetro smtp_enforce_tls é usado para exigir que o servidor SMTP remoto utilize criptografia TLS para enviar emails. Isso é útil quando você deseja garantir que todas as comunicações entre seu servidor de email e servidores remotos sejam criptografadas e que o certificado do servidor remoto seja verificado corretamente. Se você configurou o parâmetro smtpd_tls_auth_only para garantir que a autenticação do cliente seja feita apenas em conexões TLS, isso protege a comunicação entre os clientes e o seu servidor. No entanto, o smtp_enforce_tls vai além, forçando que todas as conexões com servidores remotos também usem TLS.

O uso de smtp_enforce_tls pode causar problemas de entrega se o servidor remoto não suportar TLS ou tiver um certificado inválido, pois o Postfix vai reter os emails na fila até que uma conexão segura possa ser estabelecida. Uma alternativa mais flexível é o uso de smtp_tls_security_level, que permite definir diferentes níveis de segurança para as conexões TLS, como may (opcional), encrypt (exige TLS, mas sem verificação de certificado), verify (exige TLS com verificação de certificado), e secure (exige TLS com verificação rigorosa do certificado).

Dica

O uso de smtpd_tls_security_level é uma boa prática, a opção encrypt é definina normalmente quando vamos habilitar o submission, já na configuração do main.cf, é uma boa prática usar a opção dane (DANE deve ser usado quando se deseja implementar DANE (DNS-based Authentication of Named Entities) para validar certificados usando DNSSEC). O exemplo abaixo mostra como fica no submission.

"/etc/postfix/main.cf
submission inet n       -       -       -       -       smtpd
  -o smtpd_tls_security_level=encrypt

Essa configuração ajuda a forçar o cliente a usar TLS para enviar e-mails, garantindo que a comunicação entre o cliente e o servidor seja criptografada, já que está aplicada o encrypt no submission. No entanto, outros servidores SMTP não deverão usar TLS nas conxões forçadamente para troca de mensagens.

Não confunda smtpd_tls_security_level com smtp_tls_security_level.

smtpd_tls_security_level
Controla o nível de segurança do TLS para as conexões recebidas pelo servidor Postfix.
smtp_tls_security_level
Controla o nível de segurança do TLS para as conexões enviadas pelo servidor Postfix (ou seja, conexões do seu servidor para outros servidores de email).

Gerador de Números Aleatórios

A segurança do TLS não depende apenas da criptografia, mas também da qualidade dos números aleatórios usados para criar as chaves criptográficas. Cada sessão TLS requer números aleatórios únicos para garantir que as combinações de chaves não se repitam, o que ajudaria a manter a comunicação segura. Certificados digitais e chaves privadas são gerados uma vez e usados para estabelecer conexões seguras. Os certificados são assinados por uma autoridade certificadora (CA) e as chaves privadas são usadas para criptografar e descriptografar dados. A segurança desses certificados e chaves está no fato de que eles são únicos e difíceis de serem falsificados ou comprometidos.

Cada sessão TLS requer a criação de chaves temporárias para a criptografia da comunicação entre o cliente e o servidor. Essas chaves temporárias são conhecidas como chaves de sessão e são geradas para cada nova conexão TLS. Para criar essas chaves de sessão, o TLS utiliza números aleatórios. A qualidade desses números aleatórios é crucial porque eles garantem que as chaves de sessão sejam únicas e imprevisíveis. Se os números aleatórios não forem verdadeiramente aleatórios ou se houver um padrão previsível, as chaves geradas poderiam ser comprometidas, o que afetaria a segurança da comunicação.

Resumindo o que temos em ação:

Certificado (ou Chave Pública)
É um certificado digital contém a chave pública e outras informações relevantes, como a identidade do proprietário do certificado (por exemplo, o nome do servidor e o domínio), a autoridade certificadora (CA) que assinou o certificado e o período de validade. O certificado é usado para criptografar dados e verificar a identidade do servidor. Quando um cliente se conecta a um servidor, o servidor envia seu certificado ao cliente. O cliente usa a chave pública contida no certificado para criptografar dados que serão enviados de volta ao servidor. O servidor, por sua vez, usa sua chave privada para descriptografar esses dados. O certificado também ajuda o cliente a verificar a identidade do servidor, garantindo que está se comunicando com o servidor legítimo.
Chave Privada
A chave privada é uma parte do par de chaves (chave pública e chave privada) e deve ser mantida em segredo pelo servidor. Ela é usada para descriptografar dados que foram criptografados com a chave pública correspondente. Quando o cliente criptografa dados usando a chave pública do servidor (que está no certificado), o servidor usa a chave privada para descriptografar esses dados. A chave privada nunca deve ser compartilhada e deve ser protegida rigorosamente para garantir a segurança das comunicações.
Chave Aleatória (ou Números Aleatórios)
A chave de sessão é uma chave criptográfica simétrica temporária usada para criptografar e descriptografar dados durante uma única sessão de comunicação. É como uma senha temporária que é usada apenas para uma conversa específica e é descartada após o término da sessão. No TLS, a chave de sessão é gerada durante o handshake TLS e é usada para criptografar e descriptografar dados durante a comunicação entre o cliente e o servidor. Esta chave é única para cada sessão e garante que os dados trocados entre as partes sejam seguros e privados.

No início de uma sessão TLS, o cliente e o servidor iniciam um processo chamado handshake. Durante esse handshake, o servidor envia ao cliente seu certificado digital, que contém sua chave pública e foi assinado por uma autoridade certificadora (CA) confiável. O cliente utiliza a chave pública do servidor para criptografar uma chave secreta temporária, conhecida como chave de sessão. Essa chave de sessão é então enviada de volta ao servidor. O servidor, que possui a chave privada correspondente à chave pública do certificado, usa essa chave privada para descriptografar a chave de sessão recebida. A partir desse ponto, tanto o cliente quanto o servidor utilizam a chave de sessão para criptografar e descriptografar os dados trocados durante a comunicação, incluindo o corpo das mensagens e outros dados transmitidos.

Embora a chave de sessão seja utilizada para a criptografia simétrica dos dados, garantindo uma comunicação segura e eficiente durante a sessão, as chaves pública e privada são usadas no início da comunicação para garantir que a chave de sessão seja transmitida de forma segura. A chave pública do servidor criptografa a chave de sessão, e a chave privada do servidor a descriptografa, assegurando que apenas o servidor possa acessar a chave de sessão.

Além disso, o servidor precisa de uma fonte confiável de números aleatórios para suas próprias operações internas de criptografia durante o processo de handshake. Isso inclui a geração de chaves temporárias e valores aleatórios que são fundamentais para garantir a segurança da comunicação. Por isso, é importante configurar o servidor para usar uma fonte de números aleatórios, como /dev/random ou /dev/urandom, para garantir que a criptografia e a segurança do TLS sejam mantidas adequadas e robustas, você pode usar algum hardware que faça isso também.

O OpenSSL é a biblioteca usada pelo Postfix para gerenciar TLS, criar certificado, chave, revogar e etc. Mas ele não gera os números aleatórios, em vez disso, deve-ser utilizar fontes de números aleatórios fornecidas pelo sistema operacional. Em sistemas Linux e BSD, essas fontes geralmente são:

/dev/random
Um dispositivo que fornece números aleatórios verdadeiros baseados em eventos físicos, como o movimento do mouse e a atividade do teclado. Pode ser mais lento devido à sua natureza.
/dev/urandom
Um dispositivo que fornece números aleatórios pseudo-aleatórios gerados por um algoritmo baseado em uma fonte de entropia. É mais rápido e adequado para a maioria das aplicações.

Se o seu sistema tem esses dispositivos de números aleatórios (/dev/random e /dev/urandom), o OpenSSL e, portanto, o Postfix usarão automaticamente essas fontes. Se o seu sistema não possui um gerador de números aleatórios embutido, você pode usar um daemon de gerador de números pseudo-aleatórios, como o fornecido por Lutz Jänicke. Para configurar o Postfix para usar esse daemon, você deve definir o parâmetro tls_random_source no arquivo main.cf.

Aqui está um exemplo de como configurar o Postfix para usar um gerador de números aleatórios, caso necessário:

"/etc/postfix/main.cf
tls_random_source = /dev/random

STARTTLS na comunicação SMTP

Podemos fazer teste que é executar uma sessão telnet no servidor Postfix para verificar se ele oferece TLS para clientes de e-mail. Observe atentamente a seguinte saída para a palavra-chave STARTTLS:

Terminal

# Abra conexão na porta 25 do servidor:
$ telnet localhost 25
220 mail.example.com ESMTP Postfix

# Agora se apresente:
EHLO client.example.com

# Se der tuco certo, o servidor vai exibir o '250-STARTTLS':
250-mail.wlf.eti.br
250-PIPELINING
250-SIZE 28871600
250-ETRN
250-STARTTLS
250-AUTH PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250-SMTPUTF8
250 CHUNKING

# Para sair envie:
QUIT
221 2.0.0 Bye

Forward Secrecy

A Confidencialidade Perfeita (Forward Secrecy) é um recurso de segurança em protocolos de comunicação, como TLS, que assegura que a chave de sessão usada para criptografar uma comunicação não pode ser comprometida mesmo que a chave privada do servidor seja comprometida posteriormente. Durante o início de uma sessão TLS, o servidor e o cliente geram uma nova chave de sessão temporária, usando um método de troca de chaves, como o Diffie-Hellman (DH) ou o Elliptic Curve Diffie-Hellman (ECDH). Estas chaves são geradas e usadas apenas para aquela sessão específica.

Bem basicamente, é um recurso adicional no uso de TLS que se aplica durante a negociação da chave de sessão.

A chave de sessão é usada para criptografar os dados trocados entre o cliente e o servidor durante a sessão. Uma vez que a sessão é encerrada, a chave de sessão é descartada e não pode ser recuperada. Mesmo que alguém consiga obter a chave privada do servidor no futuro, eles não poderão descriptografar as sessões passadas porque as chaves de sessão usadas para criptografá-las não estão mais disponíveis.

A segurança oferecida pela confidencialidade perfeita (forward secrecy) não protege contra ataques ativos, como respostas DNS forjadas ou certificados TLS de servidor falsificados. Se esses ataques forem uma preocupação, o cliente SMTP precisará autenticar o servidor SMTP remoto de maneira suficientemente segura, por exemplo, usando a impressão digital de uma chave pública ou certificado (CA ou específico). O PKI convencional depende de várias partes confiáveis e pode ser facilmente subvertido por adversários financiados por estados.

A confidencialidade perfeita é alcançada ao negociar chaves de sessão usando números aleatórios criptograficamente fortes que são gerados exclusivamente para aquela sessão e não são armazenados, e ao assinar a troca com chaves de autenticação de longo prazo. Embora a divulgação futura das chaves de longo prazo permita a falsificação do detentor da chave, ela não permite a recuperação do tráfego anterior. Com a confidencialidade perfeita, os dados da chave aleatória descartada não estão disponíveis para o atacante.

A confidencialidade perfeita é considerada "perfeita" quando ataques de força bruta ao algoritmo de troca de chaves são impraticáveis, mesmo para adversários bem financiados, e quando os geradores de números aleatórios utilizados por ambas as partes são suficientemente fortes. Caso contrário, a confidencialidade perfeita impõe um desafio ao atacante: quebrar o protocolo de troca de chaves, o que pode ser intensivo em termos computacionais, mas pode ser viável para sessões de valor suficientemente alto. Assim, a confidencialidade perfeita impõe restrições de custo sobre a eficácia da vigilância em massa. A recuperação de todo o tráfego passado geralmente é inviável, e a recuperação de sessões individuais pode ser inviável dado um método de troca de chaves suficientemente forte.

Forward Secrecy com TLS

As primeiras implementações do protocolo SSL não oferecem confidencialidade perfeita. Nesses casos, o cliente envia um "pre-master secret" aleatório para o servidor criptografado com a chave pública RSA do servidor. O servidor decripta essa informação com sua chave privada e usa essa chave, junto com outros dados trocados em texto claro, para gerar a chave de sessão. Um atacante com acesso à chave privada do servidor pode realizar a mesma computação a qualquer momento futuro.

As revisões posteriores do protocolo TLS introduziram suites de criptografia com confidencialidade perfeita, onde o cliente e o servidor implementam um protocolo de troca de chaves baseado em segredos efêmeros. Sessões criptografadas com essas novas suites de criptografia não são comprometidas pela divulgação futura das chaves de autenticação de longo prazo.

Os algoritmos de troca de chaves usados para a confidencialidade perfeita requerem que o servidor TLS defina "parâmetros" apropriados, consistindo em um "grupo" matemático e um elemento desse grupo chamado de "gerador". Atualmente, existem duas categorias de "grupos" que trabalham com PFS (Perfect Forward Secrecy):

FFDHE (Finite-field Diffie-Hellman Ephemeral): Grupos de troca de chaves efêmeros usando o algoritmo Diffie-Hellman com campo finito. O servidor deve ser configurado com um primo e um "gerador" adequados. As escolhas padrão para o primo e o gerador são especificadas no RFC 7919 e podem ser usadas no protocolo TLS 1.3, com o servidor e o cliente negociando uma escolha mutuamente suportada. Nas versões anteriores do TLS (1.0 a 1.2), quando a troca de chaves FFDHE é realizada, o servidor escolhe o primo e o gerador unilateralmente.
EECDH (Ephemeral Elliptic Curve Diffie-Hellman): Oferece melhor segurança a um custo computacional menor do que o FFDHE. Curvas elípticas usadas em criptografia são tipicamente identificadas por um "nome" que representa um conjunto de valores de parâmetro bem conhecidos, e são esses "nomes de curvas" (ou identificadores de objeto ASN.1 associados em certificados) que são usados no protocolo TLS. Quando a troca de chaves EECDH é usada, uma curva nomeada mutuamente suportada é negociada como parte do handshake TLS.

Atualmente, a maioria dos clientes SMTP remotos suporta a confidencialidade perfeita (sendo a única opção a partir do TLS 1.3), mas alguns ainda podem preferir suítes de criptografia sem essa característica. Servidores Postfix na versão 2.8 ou superior podem ser configurados para substituir a preferência do cliente, ajustando a configuração tls_preempt_cipherlist = yes.

A partir do Postfix 3.1, é possível utilizar o grupo de troca de chaves finito-difícil (FFDHE) com primos de 2048 bits sem necessidade de configuração adicional. Embora seja possível gerar seus próprios parâmetros FFDHE, isso não é mais necessário nem recomendado. O Postfix 3.8 introduz o suporte à negociação do grupo de troca de chaves FFDHE da API OpenSSL ≥ 3.0. Com o TLS 1.3, os grupos FFDHE são negociados explicitamente entre cliente e servidor. Em versões anteriores do TLS, o servidor escolhe o grupo unilateralmente. A lista de grupos FFDHE candidatos pode ser configurada através do parâmetro tls_ffdhe_auto_groups, que permite selecionar uma lista priorizada de grupos suportados (do mais preferido ao menos preferido) tanto no servidor quanto no cliente.

A lista padrão é adequada para a maioria dos usuários. Pode-se deixar vazio um dos parâmetros tls_eecdh_auto_curves ou tls_ffdhe_auto_groups, desativando assim a troca de chaves EC ou FFDHE no OpenSSL 3.0 com TLS 1.3. Contudo, a interoperabilidade pode ser comprometida se todas as curvas EC estiverem desativadas ou não incluírem as curvas mais amplamente utilizadas.

Desde o Postfix 3.2 e OpenSSL 1.0.2, uma gama de curvas EECDH suportadas está habilitada no servidor e cliente, e uma curva mutuamente suportada é negociada durante o handshake do TLS. A lista de curvas suportadas pode ser configurada pelo parâmetro tls_eecdh_auto_curves. Com o TLS 1.2, o servidor deve manter a configuração padrão de smtpd_tls_eecdh_grade em auto, uma vez que escolhas explícitas de uma única curva foram descontinuadas. Com o TLS 1.3, o parâmetro smtpd_tls_eecdh_grade não é utilizado, e a seleção da curva é negociada incondicionalmente.

Melhores configurações para TLS

Até agora, exploramos várias opções para utilizar o TLS e algumas configurações básicas para proteger um servidor SMTP com autenticação. No entanto, essas abordagens iniciais são apenas o começo para garantir uma segurança robusta. Neste tópico, vamos aprofundar nas melhores práticas e configurações avançadas para otimizar o uso do TLS no Postfix.

Até o momento temos algo parecido com as opções abaixo, sem contar o que vimos de como configurar o Submission.

/etc/postfix/main.cf
# Ativa o TLS:
smtpd_use_tls = yes
# Autenticação do cliente acontece apenas em conexões TLS:
smtpd_tls_auth_only = yes
# Chave privada:
smtpd_tls_key_file = ${config_directory}/certs/privkey.pem
# Certificado contendo a chave publica:
smtpd_tls_cert_file = ${config_directory}/certs/fullchain.pem
# Não aceita Autenticação do cliente em texto simples e recusa cliente anonimo: 
smtpd_sasl_security_options = noanonymous, noplaintext
# Recusa a autenticação do cliente anonimo:
smtpd_sasl_tls_security_options = noanonymous
# Configura uma fonte confiável de aleatoriedade:
tls_random_source = /dev/random

# Adicionalmente, é uma prática configurar os logs:
smtpd_tls_loglevel = 1
smtp_tls_loglevel = 1

Essas opções são algo essencial para um sistema com autenticação de usuário, mas podemos melhorar e muito a parte de TLS.

Vamos forçar o uso do TLS sempre

Para garantir que o TLS seja sempre utilizado, vamos adicionar:

/etc/postfix/main.cf
smtpd_tls_security_level = may

Vamos usar may para que o servidor anuncia suporte para STARTTLS para clientes SMTP remotos, mas não exige que os clientes usem criptografia TLS, tornando o uso de TLS opcional para os clientes SMTP. Isso é útil em casos onde o cliente não suporte TLS.

Melhorando a geração de Chaves de Sessão

Ao armazenar chaves de sessão em um cache compartilhado, o servidor pode evitar o esforço computacional repetitivo necessário para recalcular chaves de sessão para conexões TLS subsequentes. Isso não apenas melhora o desempenho do servidor, mas também otimiza o uso de recursos, permitindo que o servidor gerencie um grande número de sessões TLS simultâneas sem degradar significativamente o desempenho.

/etc/postfix/main.cf
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache

Configuração de Protocolos e Cifras

Vamos definir os protocolos e cifras recomendados para evitar o uso de métodos obsoletos e menos seguros:

/etc/postfix/main.cf
# Protocolos em SMTP
smtp_tls_protocols = >=TLSv1.2, <=TLSv1.3
smtp_tls_mandatory_protocols = >=TLSv1.2, <=TLSv1.3

# Protocolos em SMTPD
smtpd_tls_protocols = >=TLSv1.2, <=TLSv1.3
smtpd_tls_mandatory_protocols = >=TLSv1.2, <=TLSv1.3

# Cifras em SMTP
smtp_tls_ciphers = high
smtp_tls_mandatory_ciphers = high
smtp_tls_exclude_ciphers = aNULL,eNULL,EXPORT,DES,RC4,MD5,PSK,aECDH,EDH-DSS-DES-CBC3-SHA,EDH-RSA-DES-CBC3-SHA,KRB5-DES,CBC3-SHA,DES-CBC3-SHA,AES128-SHA,AES256-SHA,AES128-SHA256,AES128-GCM-SHA256,AES256-SHA256,DHE-RSA-DES-CBC3-SHA,AES256-GCM-SHA384,ECDHE-ECDSA-DES-CBC3-SHA,ECDHE-RSA-DES-CBC3-SHA,CAMELLIA256-SHA256,CAMELLIA256-SHA,CAMELLIA128-SHA256,CAMELLIA128-SHA

# Cifras em SMTPD
smtpd_tls_ciphers = high
smtpd_tls_mandatory_ciphers = high
smtpd_tls_exclude_ciphers = aNULL,eNULL,EXPORT,DES,RC4,MD5,PSK,aECDH,EDH-DSS-DES-CBC3-SHA,EDH-RSA-DES-CBC3-SHA,KRB5-DES,CBC3-SHA,DES-CBC3-SHA,AES128-SHA,AES256-SHA,AES128-SHA256,AES128-GCM-SHA256,AES256-SHA256,DHE-RSA-DES-CBC3-SHA,AES256-GCM-SHA384,ECDHE-ECDSA-DES-CBC3-SHA,ECDHE-RSA-DES-CBC3-SHA,CAMELLIA256-SHA256,CAMELLIA256-SHA,CAMELLIA128-SHA256,CAMELLIA128-SHA

# Configurações gerais:
tls_preempt_cipherlist = yes
tls_high_cipherlist = ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256

As configurações de TLS e cifragem que estamos usando para o Postfix têm como objetivo garantir uma comunicação segura e eficiente, limitando o uso de protocolos e cifras obsoletos ou vulneráveis e priorizando as melhores práticas de segurança. As configurações abaixo definem quais versões do protocolo TLS são permitidas para conexões SMTP (envio de e-mails) e SMTPD (recebimento de e-mails). Ao limitar os protocolos a TLS 1.2 e TLS 1.3, estamos garantindo que apenas versões modernas e seguras do TLS sejam utilizadas, evitando protocolos antigos e vulneráveis como TLS 1.0 e TLS 1.1, que têm várias vulnerabilidades conhecidas. Além disso, a configuramos já usa a nova sintaxe (a partir da versão 3.6 do Postfix).

# Protocolos em SMTP
smtp_tls_protocols = >=TLSv1.2, <=TLSv1.3
smtp_tls_mandatory_protocols = >=TLSv1.2, <=TLSv1.3

# Protocolos em SMTPD
smtpd_tls_protocols = >=TLSv1.2, <=TLSv1.3
smtpd_tls_mandatory_protocols = >=TLSv1.2, <=TLSv1.3

As configurações abaixo definem quais cifras de criptografia são permitidas e quais devem ser excluídas para conexões SMTP e SMTPD.

# Cifras em SMTP
smtp_tls_ciphers = high
smtp_tls_mandatory_ciphers = high
smtp_tls_exclude_ciphers = aNULL,eNULL,EXPORT,DES,RC4,MD5,PSK,aECDH,EDH-DSS-DES-CBC3-SHA,EDH-RSA-DES-CBC3-SHA,KRB5-DES,CBC3-SHA,DES-CBC3-SHA,AES128-SHA,AES256-SHA,AES128-SHA256,AES128-GCM-SHA256,AES256-SHA256,DHE-RSA-DES-CBC3-SHA,AES256-GCM-SHA384,ECDHE-ECDSA-DES-CBC3-SHA,ECDHE-RSA-DES-CBC3-SHA,CAMELLIA256-SHA256,CAMELLIA256-SHA,CAMELLIA128-SHA256,CAMELLIA128-SHA

# Cifras em SMTPD
smtpd_tls_ciphers = high
smtpd_tls_mandatory_ciphers = high
smtpd_tls_exclude_ciphers = aNULL,eNULL,EXPORT,DES,RC4,MD5,PSK,aECDH,EDH-DSS-DES-CBC3-SHA,EDH-RSA-DES-CBC3-SHA,KRB5-DES,CBC3-SHA,DES-CBC3-SHA,AES128-SHA,AES256-SHA,AES128-SHA256,AES128-GCM-SHA256,AES256-SHA256,DHE-RSA-DES-CBC3-SHA,AES256-GCM-SHA384,ECDHE-ECDSA-DES-CBC3-SHA,ECDHE-RSA-DES-CBC3-SHA,CAMELLIA256-SHA256,CAMELLIA256-SHA,CAMELLIA128-SHA256,CAMELLIA128-SHA

smtp_tls_ciphers = high e smtpd_tls_ciphers = high indicam que apenas cifras de alta segurança devem ser usadas. Cifras de alta segurança garantem uma criptografia forte e segura.

smtp_tls_exclude_ciphers e smtpd_tls_exclude_ciphers listam as cifras que devem ser explicitamente excluídas devido a suas vulnerabilidades conhecidas. Isso inclui cifras desatualizadas e algoritmos que oferecem segurança insuficiente, como DES e RC4.

As configurações abaixo garante que a lista de cifras preferenciais seja usada (tls_preempt_cipherlist), além disso, definem como a lista de cifras é gerada e priorizada (tls_high_cipherlist). Essas cifras foram escolhidas por sua robustez e resistência a ataques

tls_preempt_cipherlist = yes
tls_high_cipherlist = ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256

Dica

Como saber quais cifras são fortes e quais são fracas? Basicamente é um trabalho árduo correr atrás dessas informações. Em documentação como OpenSSL podemos obter informações sobre as cifras suportadas e suas classificações e usar essa avaliação da equipe do SSL. Também podemos consulte diretrizes de segurança como o OWASP e recomendações da NIST para informações sobre cifras recomendadas e obsoletas.

Também podemos usar ferramentas como ssl-config-generator da Mozilla, só cuidado que a versão descritas de algumas ferramentas um pouco desatualizada, mas é um bom começo para se ter uma base.

Outra forma de saber boas cifras é com o openssl usando o comando openssl ciphers -v, podemos filtrar e usar apenas as cifras de TLS1.2 para cima. Um outro utilitário que pode ser usado para fazer algumas verificações é o testssl.sh, mas tome cuidado, é script, use por sua conta e risco.

Uma última dica é usar sites como top.nic.br e internet.nl para testar a conformidade de sites e servidores de email com as normas e boas práticas da internet, como IPv6, DNSSEC, HTTPS, STARTTLS, entre outras.

Finalizando a configuração

Agora que temos quase tudo pronto, vamos finalizar com algumas opções que são "genéricas", mas não deixam de serem muito importante.

/etc/postfix/main.cf
# Especifica o arquivo Diffie-Hellman de 4096 bits:
smtpd_tls_dh1024_param_file = ${config_directory}/certs/ffdhe4096.pem

# Desativa a retomada de sessão TLS usando tickets;
# Desativa a compressão SSL, mesmo que suportada pela biblioteca OpenSSL;
# Impede renegociações TLS;
# Desativa a retomada de sessão se houver renegociação.
tls_ssl_options = NO_TICKET, NO_COMPRESSION, NO_RENEGOTIATION, NO_SESSION_RESUMPTION_ON_RENEGOTIATION

# Armazenar chaves de sessão em um cache compartilhado:
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

# Ativa as consultas DNS com suporte ao DNSSEC:
smtp_dns_support_level = dnssec 

# A política TLS para o destino é obtida via DNSSEC:
smtp_tls_security_level = dane

O parâmetro smtpd_tls_dh1024_param_file especifica o arquivo contendo parâmetros de Diffie-Hellman (DH) para troca segura de chaves durante a negociação de TLS. Essa configuração define o arquivo que contém os parâmetros DH para o servidor SMTP. O tamanho do parâmetro DH de 4096 bits (ffdhe4096.pem) oferece uma segurança robusta contra ataques de quebra de criptografia, proporcionando uma troca de chaves segura.

# Especifica o arquivo Diffie-Hellman de 4096 bits:
smtpd_tls_dh1024_param_file = ${config_directory}/certs/ffdhe4096.pem

O parâmetro tls_ssl_options configura opções específicas de TLS para melhorar a segurança.

NO_TICKET: Desativa a retomada de sessão TLS usando tickets, que pode ser uma fonte de vulnerabilidades se não for gerenciada corretamente.
NO_COMPRESSION: Desativa a compressão SSL, o que pode evitar ataques como o ataque CRIME, que explora a compressão para recuperar dados criptografados.
NO_RENEGOTIATION: Impede a renegociação TLS, o que pode proteger contra ataques que exploram a renegociação para injetar dados ou comprometer a segurança da sessão.
NO_SESSION_RESUMPTION_ON_RENEGOTIATION: Desativa a retomada de sessão se houver renegociação, o que é uma prática de segurança adicional para evitar problemas de segurança associados à renegociação de sessão.

# Desativa a retomada de sessão TLS usando tickets;
# Desativa a compressão SSL, mesmo que suportada pela biblioteca OpenSSL;
# Impede renegociações TLS;
# Desativa a retomada de sessão se houver renegociação.
tls_ssl_options = NO_TICKET, NO_COMPRESSION, NO_RENEGOTIATION, NO_SESSION_RESUMPTION_ON_RENEGOTIATION

A opção smtp_tls_session_cache_database especifica onde as chaves de sessão TLS devem ser armazenadas. Usar um cache compartilhado (btree:${data_directory}/smtp_scache) ajuda a melhorar a eficiência ao reutilizar sessões TLS existentes e reduzir o tempo necessário para estabelecer novas conexões, mantendo a segurança.

# Armazenar chaves de sessão em um cache compartilhado:
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

A opção smtp_dns_support_level = dnssec ativa o suporte ao DNSSEC, que fornece uma camada adicional de segurança para consultas DNS, garantindo a integridade e autenticidade das respostas DNS. Isso ajuda a proteger contra ataques de spoofing e outras ameaças relacionadas ao DNS, mas é necessário que você configure e use DNSSEC onde o registro MX do servidor SMTP estiver.

# Ativa as consultas DNS com suporte ao DNSSEC:
smtp_dns_support_level = dnssec 

A opção smtp_tls_security_level = dane indica que a política TLS deve ser obtida usando DNS-based Authentication of Named Entities (DANE). O DANE usa DNSSEC para fornecer certificados TLS autênticos para domínios, oferecendo uma forma adicional de validação de segurança para as conexões SMTP. Mas para que isso funcione, você deve configurar TLSA no DNS para o seu servidor SMTP (veremos depois sobre TLSA).

# A política TLS para o destino é obtida via DNSSEC:
smtp_tls_security_level = dane

Performance do servidor

A criptografia, embora essencial para garantir a confidencialidade e a integridade das comunicações, pode impor uma carga significativa no processador, especialmente durante o processo de handshake TLS, onde operações criptográficas de chave privada são realizadas. Para mitigar o impacto no desempenho causado pela criptografia, é crucial implementar práticas como o uso de um cache de chaves de sessão TLS. Ao armazenar chaves de sessão em um cache compartilhado, o servidor pode evitar o esforço computacional repetitivo necessário para recalcular chaves de sessão para conexões TLS subsequentes. Isso não apenas melhora o desempenho do servidor, mas também otimiza o uso de recursos, permitindo que o servidor gerencie um grande número de sessões TLS simultâneas sem degradar significativamente o desempenho.

Além disso, o uso de daemons como o tlsmgr para gerenciar o cache de chaves de sessão é vital para garantir que as chaves expiradas sejam removidas e que o cache não cresça descontroladamente. Isso destaca a necessidade de uma manutenção contínua e adequada das configurações do servidor para assegurar que ele opere de maneira eficiente e segura. Para criar o cache, primeiro vamos definir o tipo de banco de dados que será usado para armazenar o cache e o caminho onde as chaves de sessão serão armazenadas. A configuração abaixo normalmente é a padrão após instalar o Postfix:

"/etc/postfix/main.cf
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache

Agora especifique o tempo em segundos antes que as chaves de sessão no cache expirem. O padrão é 3600 segundos (1 hora).

"/etc/postfix/main.cf
smtpd_tls_session_cache_timeout = 3600

DICA

Não coloque o banco de dados do cache de sessão TLS em um ambiente chroot, pois se comprometido, ele pode ser usado para enganar clientes de e-mail, fazendo-os acreditar que estão se comunicando com um servidor seguro. O daemon tlsmgr pode rodar em chroot, pois ele abre o banco de dados antes de alterar o diretório raiz, permitindo leitura e gravação enquanto chrooted.

Daemon tlsmgr

O daemon tlsmgr é responsável por manter o cache de chaves de sessão, limpando as chaves expiradas e gerenciando o banco de dados de cache. Certifique-se de que ele esteja ativado no arquivo master.cf. Abra o arquivo master.cf e certifique-se de que a linha referente ao tlsmgr não esteja comentada:

"/etc/postfix/master.cf
tlsmgr   unix  -       -       n       1000?   1       tlsmgr

Após configurar os parâmetros acima, reinicie o Postfix para aplicar as alterações:

$ sudo systemctl restart postfix

Implementar o cache de chaves de sessão TLS desta forma ajuda a melhorar o desempenho do servidor, especialmente quando ele lida com um grande número de sessões TLS simultâneas. Além disso, manter o tlsmgr ativo garante que o cache seja gerenciado de maneira eficiente e segura.

Rate Limit

Mesmo em instalações bem configuradas do Postfix, a capacidade do servidor de lidar com tráfego de e-mail é limitada. Diversos fatores influenciam essa capacidade, incluindo a taxa de transferência de E/S de disco, a velocidade da CPU e o desempenho de qualquer software antivírus integrado ao Postfix. Esses componentes afetam a quantidade de e-mails que o servidor pode processar de maneira eficiente.

Para garantir que o servidor de e-mail não seja sobrecarregado e mantenha um desempenho estável, é crucial implementar e ajustar limites de taxa. Os limites de taxa ajudam a evitar que o servidor seja inundado com uma quantidade excessiva de conexões ou mensagens em um curto período, o que pode levar a um consumo excessivo de recursos e eventualmente a uma queda no serviço.

O anvil é um componente do Postfix que gerencia e limita a taxa de conexões e o acesso ao serviço SMTP. Ele faz parte do sistema de gerenciamento de recursos do Postfix e é utilizado para proteger o servidor de ataques de negação de serviço (DoS) e para garantir que o servidor funcione de maneira eficiente sob cargas pesadas. Aqui estão algumas das principais funções e usos do anvil:

Limitação de Taxa de Conexões
O anvil controla a taxa de novas conexões e o número de conexões simultâneas que um cliente pode abrir para o servidor. Isso ajuda a evitar sobrecargas no servidor causadas por um grande número de conexões simultâneas ou tentativas excessivas de conexão.
Proteção Contra Abusos
Ele ajuda a prevenir abusos, como ataques de força bruta ou outras tentativas de exploração que podem resultar em um grande número de tentativas de conexão falhadas. Por exemplo, se um cliente tenta se conectar repetidamente com credenciais incorretas, o anvil pode limitar o número de tentativas permitidas.
Controle de Recursos
O anvil pode ser configurado para controlar o uso de recursos, como limitar o número de mensagens que um remetente pode enviar em um determinado período de tempo.
Registro de Atividades
Ele fornece estatísticas e informações sobre a atividade de conexão, que podem ser úteis para análise e monitoramento de segurança.

Configurando o anvil

O anvil é configurado principalmente através do arquivo de configuração master.cf, onde você define as opções de serviço para os daemons do Postfix. Abaixo está um exemplo básico de configuração do anvil:

"/etc/postfix/master.cf
anvil  unix  -       -       n       -       1       anvil
  -o anvil_rate_limit = 200/m
  -o anvil_connect_rate_limit = 100/h

O anvil_rate_limit define o número máximo de mensagens que um remetente pode enviar em um determinado período (por exemplo, 200 mensagens por minuto). Já o anvil_connect_rate_limit define o número máximo de conexões que um cliente pode iniciar em um determinado período (por exemplo, 100 conexões por hora).

Limitando a frequência de conexão do cliente

Por padrão, o Postfix não impõe um limite no número de vezes sucessivas que um cliente pode se conectar ao servidor. Sem ajustes, um cliente pode se conectar e desconectar quantas vezes desejar, o que pode levar a um desperdício significativo de recursos do servidor. Isso inclui o processamento de pesquisas de DNS, handshakes TLS e outras operações que consomem recursos.

Para evitar esse problema e impor um limite à frequência de conexões dos clientes, podemos usar o parâmetro smtpd_client_connection_count_limit. Esse parâmetro é usado para controlar o número máximo de tentativas de conexão que qualquer cliente pode fazer ao serviço de SMTP dentro de uma unidade de tempo especificada. O período de tempo para o limite de conexões é definido pelo parâmetro anvil_rate_time_unit. Por padrão, a unidade de tempo é de um minuto (60 segundos), mas você pode configurá-la conforme necessário.

"/etc/postfix/main.cf
smtpd_client_connection_count_limit = 10

Con a configuração acima, temos o seguinte comportamento. O cliente pode fazer até 10 tentativas de conexão em um período de 60 segundos. Isso inclui tentativas de conexão ao servidor SMTP. Se um cliente exceder 10 tentativas de conexão dentro desse período de 60 segundos, o servidor pode aplicar uma limitação ou rejeitar novas conexões do cliente até que o período de 60 segundos expire. Isso ajuda a prevenir abusos, como ataques de força bruta. Esse limite de 10 conexões por minuto não se refere especificamente a tentativas de login falhas, mas sim ao número total de tentativas de conexão do cliente. Se a configuração também deseja limitar especificamente tentativas de login, é necessário configurar parâmetros adicionais relacionados a autenticação e segurança.

Autenticação SMTP​

SASL - Simple Authentication and Security Layer​

Interface de autenticação​

Mecanismos de Autenticação SMTP​

Serviços de Verificação de Senha​

saslauthd​

auxprop​

Backends de autenticação​

Configuração do SASL para Aplicações​

Configurando o saslauthd​

Configurando o saslauthd com o PAM​

Configurando o saslauthd com o LDAP​

Configurando o Postfix para usar autenticação​

Postfix com Cyrus SASL​

Postfix com Dovecot SASL​

Introdução do TLS​

O Problema que o TLS Resolve​

Conceitos Básicos de TLS​

Como o TLS Funciona​

Certificados​

Root Store​

Preparando o Postfix para receber certificado​

Habilitando TLS no Postfix​

Controlando mecanismos SASL em TLS​

Forçando toda comunicação com TLS​

Gerador de Números Aleatórios​

STARTTLS na comunicação SMTP​

Forward Secrecy​

Forward Secrecy com TLS​

Melhores configurações para TLS​

Vamos forçar o uso do TLS sempre​

Melhorando a geração de Chaves de Sessão​

Configuração de Protocolos e Cifras​

Finalizando a configuração​

Performance do servidor​

Daemon tlsmgr​

Rate Limit​

Configurando o anvil​

Limitando a frequência de conexão do cliente​

Autenticação SMTP

SASL - Simple Authentication and Security Layer

Interface de autenticação

Mecanismos de Autenticação SMTP

Serviços de Verificação de Senha

saslauthd

auxprop

Backends de autenticação

Configuração do SASL para Aplicações

Configurando o saslauthd

Configurando o saslauthd com o PAM

Configurando o saslauthd com o LDAP

Configurando o Postfix para usar autenticação

Postfix com Cyrus SASL

Postfix com Dovecot SASL

Introdução do TLS

O Problema que o TLS Resolve

Conceitos Básicos de TLS

Como o TLS Funciona

Certificados

Root Store

Preparando o Postfix para receber certificado

Habilitando TLS no Postfix

Controlando mecanismos SASL em TLS

Forçando toda comunicação com TLS

Gerador de Números Aleatórios

STARTTLS na comunicação SMTP

Forward Secrecy

Forward Secrecy com TLS

Melhores configurações para TLS

Vamos forçar o uso do TLS sempre

Melhorando a geração de Chaves de Sessão

Configuração de Protocolos e Cifras

Finalizando a configuração

Performance do servidor

Daemon tlsmgr

Rate Limit

Configurando o anvil

Limitando a frequência de conexão do cliente