Como Configurar MTA-STS e TLS Reporting para o seu Domínio Usando o Apache no Ubuntu 18.04

O autor escolheu a Electronic Frontier Foundation Inc para receber uma doação como parte do programa Write for DOnations.

Introdução

O Mail Transport Agent Strict Transport Security (MTA-STS) é um novo padrão da Internet que lhe permite ativar o force-TLS estrito para emails enviados entre provedores de e-mail suportados. Ele é similar ao HTTP Strict Transport Security (HSTS), onde uma política force-TLS é definida e armazenada em cache por um período especificado, reduzindo o risco de ataques do tipo man-in-the-middle ou de downgrade.

O MTA-STS é complementado pelo SMTP TLS Reporting (TLSRPT), que fornece informações sobre quais e-mails são entregues com sucesso por TLS e quais não. O TLSRPT é semelhante ao DMARC reporting, mas para TLS.

O principal motivo para implementar o MTA-STS para o seu domínio é garantir que o e-mail confidencial enviado a você seja transmitido com segurança pelo TLS. Outros métodos para incentivar o TLS para comunicações por e-mail, como o STARTTLS, ainda são suscetíveis a ataques do tipo man-in-the-middle, pois a conexão inicial não é criptografada. O MTA-STS ajuda a garantir que, uma vez estabelecida pelo menos uma conexão segura, o TLS será usado por padrão a partir de então, o que reduz bastante o risco desses ataques.

Um exemplo de caso de uso para o MTA-STS e o TLS Reporting é ajudar a criar um sistema seguro de atendimento ao cliente para o seu negócio. Os clientes podem enviar tíquetes de suporte por e-mail que contêm informações pessoais confidenciais, que precisam de uma conexão TLS segura. O MTA-STS ajuda a garantir a segurança da conexão, e o TLSRPT fornece relatórios diários identificando todos os e-mails que não foram enviados com segurança — fornecendo informações cruciais sobre quaisquer ataques em andamento ou anteriores ao seu sistema de e-mail.

Neste tutorial, você aprenderá como configurar o MTA-STS e o TLSRPT para o seu nome de domínio e depois interpretar o seu primeiro relatório TLS. Embora este tutorial cubra as etapas para o uso do Apache no Ubuntu 18.04 com um certificado Let’s Encrypt, a configuração do MTA-STS/TLSRPT também funcionará em alternativas, como o Nginx no Debian.

Pré-requisitos

Antes de começar este guia, você precisará de:

• Um nome de domínio já configurado para receber e-mail, usando seu próprio servidor de e-mail ou um serviço de e-mail hospedado, como o G Suite ou o Office 365. Este tutorial usará seu-domínio por toda parte, no entanto, isso deve ser substituído por seu próprio nome de domínio. Você precisará configurar um subdomínio como parte do tutorial, para garantir que você possa acessar as configurações de DNS do seu domínio.

• Um servidor Ubuntu 18.04 configurado seguindo o tutorial Configuração Inicial de servidor com Ubuntu 18.04, incluindo um usuário sudo não-root.

• Um servidor web Apache configurado seguindo o tutorial Como Instalar o Servidor Web Apache no Ubuntu 18.04.

• Um cliente Certbot configurado para adquirir um certificado Let’s Encrypt, seguindo o tutorial Como proteger o Apache com o Let’s Encrypt no Ubuntu 18.04.

Depois de estar com tudo isso pronto, efetue login no servidor como usuário não-root para começar.

Passo 1 — Criando um Arquivo de Política MTA-STS

O MTA-STS é ativado e configurado usando um arquivo de configuração de texto sem formatação que você hospeda no seu site. Os servidores de e-mail suportados se conectarão automaticamente ao seu site para buscar o arquivo, o que faz com que o MTA-STS seja ativado. Nesta primeira etapa, você entenderá as opções disponíveis para esse arquivo e escolherá as mais adequadas para ele.

Primeiro, abra um novo arquivo de texto em seu diretório home para que você tenha um lugar para anotar a sua configuração desejada:

nano mta-sts.txt

Vamos examinar primeiramente um exemplo e, em seguida, você escreverá seu próprio arquivo de configuração.

A seguir, é apresentado um exemplo de um arquivo de configuração do MTA-STS:

version: STSv1
mode: enforce
mx: mail1.seu-domínio
mx: mail2.seu-domínio
max_age: 604800

Este arquivo de configuração de exemplo especifica que todos os emails entregues a mail1.seu-domínio e mail2.seu-domínio de provedores suportados devem ser entregues por uma conexão TLS válida. Se uma conexão TLS válida não puder ser estabelecida com o seu servidor de correio (por exemplo, se o certificado expirou ou é autoassinado), o email não será entregue.

Isso tornará muito mais desafiador para um invasor interceptar e bisbilhotar/modificar seu e-mail em uma situação como um ataque man-in-the-middle. Isso ocorre porque o MTA-STS ativado corretamente permite que o e-mail seja transmitido apenas por uma conexão TLS válida, o que requer um certificado TLS válido. Seria difícil para um invasor adquirir esse certificado, pois isso geralmente requer acesso privilegiado ao seu nome de domínio e/ou site.

Conforme mostrado no exemplo anterior neste passo, o arquivo de configuração consiste em vários pares de chave/valor:

• version:

  • Propósito: Para especificar a versão da especificação MTA-STS a ser usada.
  • Valores Aceitos: Atualmente, o único valor aceito é STSv1.
  • Exemplo: version: STSv1

• mode:

  • Propósito: Especificar em qual modo o MTA-STS deve ser ativado.
  • Valores Aceitos:
    • enforce: Forçar todos os emails de fornecedores suportados a usar TLS válido.
    • testing: Modo somente de relatório. O e-mail não será bloqueado, mas os relatórios TLSRPT ainda serão enviados.
    • none: Desativar MTA-STS.
  • Exemplo: mode: enforce

• mx:

  • Propósito: Para especificar quais servidores de e-mail têm permissão para manipular e-mails do seu domínio. Isso deve corresponder aos servidores especificados em seus registros mx.
  • Valores Aceitos: Nome de domínio totalmente qualificado de um servidor de e-mail ou um host curinga. Vários valores mx: devem ser usados para especificar vários servidores de correio.
  • Exemplo: mx: mail1.seu-domínio, mx: mail2.seu-domínio, mx: *.example.org

• max_age:

  • Propósito: Para especificar a duração máxima da política MTA-STS, em segundos.
  • Valores Aceitos: Qualquer número inteiro positivo até 31557600.
  • Exemplo: max_age: 604800 (1 semana)

Você também pode visualizar a especificação oficial para os pares de chave/valor na Seção 3.2 do RFC do MTA-STS.

Usando o arquivo de exemplo anterior, bem como os exemplos anteriores de pares de chave/valor, escreva o arquivo de política MTA-STS desejado e salve-o no arquivo que você criou no início da etapa.

O arquivo de exemplo a seguir é ideal para testar o MTA-STS, pois não fará com que nenhum e-mail seja bloqueado inesperadamente, e tem um max_age de apenas 1 dia, o que significa que se você decidir desativá-lo, a configuração expirará rapidamente. Observe que alguns provedores de e-mail somente enviarão relatórios TLSRPT se o max_age for maior que 1 dia, razão pela qual 86401 segundos é uma boa opção (1 dia e 1 segundo).

version: STSv1
mode: testing
mx: mail1.seu-domínio
mx: mail2.seu-domínio
max_age: 86401

Neste passo, você criou o arquivo de configuração MTA-STS desejado e o salvou no seu diretório home. No próximo passo, você configurará um servidor web Apache para servir o arquivo no formato correto.

Passo 2 — Configurando o Apache para Servir seu Arquivo de Políticas do MTA-STS

Neste passo, você irá configurar um virtual host no Apache para servir o seu arquivo de configuração do MTA-STS e adicionará um registro DNS para permitir que o site seja acessado a partir de um subdomínio.

Para que seu arquivo de configuração MTA-STS seja descoberto automaticamente pelos servidores de correio, ele deve ser exibido exatamente no caminho certo: https://mta-sts.seu-domínio/.well-known/mta-sts.txt. Você deve usar o subdomínio mta-sts sobre HTTPS e o caminho /.well-known/mta-sts.txt, caso contrário sua configuração não funcionará.

Isso pode ser conseguido com a criação de um novo virtual host no Apache para o subdomínio mta-sts, que servirá o arquivo de políticas do MTA-STS. Este passo baseia-se na configuração básica que você definiu no passo de pré-requisito Como Instalar o Servidor Web Apache no Ubuntu 18.04.

Primeiro, crie um diretório para o seu virtual host:

sudo mkdir /var/www/mta-sts

Se você estiver hospedando vários domínios diferentes no seu servidor web, é recomendável usar um virtual host MTA-STS diferente para cada um, por exemplo, /var/www/mta-sts-site1 and /var/www/mta-sts-site2

Em seguida, você precisa criar o diretório .well-known, que é onde seu arquivo de configuração do MTA-STS será armazenado. .well-known é um diretório padronizado para arquivos ‘well-known’, como arquivos de validação de certificado TLS, security.txt, entre outros.

sudo mkdir /var/www/mta-sts/.well-known

Agora você pode mover o arquivo de políticas MTA-STS que você criou no Passo 1 para o diretório do servidor web que você acabou de criar:

sudo mv ~/mta-sts.txt /var/www/mta-sts/.well-known/mta-sts.txt

Você pode verificar se o arquivo foi copiado corretamente, se desejar:

cat /var/www/mta-sts/.well-known/mta-sts.txt

Isso exibirá o conteúdo do arquivo que você criou no Passo 1.

Para que o Apache sirva o arquivo, você precisará configurar o novo virtual host e ativá-lo. O MTA-STS funciona apenas em HTTPS, portanto você usará a porta 443 (HTTPS) exclusivamente, em vez de usar também a porta 80 (HTTP).

Primeiro, crie um novo arquivo de configuração para o virtual host:

sudo nano /etc/apache2/sites-available/mta-sts.conf

Como no diretório do virtual host, se você estiver hospedando vários domínios diferentes no mesmo servidor web, é recomendável usar um nome de virtual host diferente para cada um.

Em seguida, copie a seguinte configuração de exemplo no arquivo e preencha as variáveis onde necessário:

<IfModule mod_ssl.c>
<VirtualHost endereço-ipv4-do-seu-servidor:443 [endereço-ipv6-do-seu-servidor]:443>
    ServerName mta-sts.seu-domínio
    DocumentRoot /var/www/mta-sts

    ErrorDocument 403 "403 Forbidden - This site is used to specify the MTA-STS policy for this domain, please see '/.well-known/mta-sts.txt'. If you were not expecting to see this, please use <a href=\"https://seu-domínio\" rel=\"noopener\">https://seu-domínio</a> instead."

    RewriteEngine On
    RewriteOptions IgnoreInherit
    RewriteRule !^/.well-known/mta-sts.txt - [L,R=403]

    SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem
    SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
    Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>
</IfModule>

Esta configuração criará o virtual host mta-sts, que será servido em mta-sts.seu-domínio. Ele também redirecionará todas as solicitações, exceto aquelas para o próprio arquivo mta-sts.txt, para uma página de erro 403 Forbidden personalizada, com uma explicação amigável, falando para que serve o site do subdomínio. Isso é para ajudar a garantir que os visitantes que encontrarem acidentalmente seu site MTA-STS não fiquem confusos.

Atualmente, um certificado TLS autoassinado é utilizado. Isso não é o ideal, pois é necessário um certificado totalmente válido/confiável para o MTA-STS funcionar corretamente. No Passo 3, você adquirirá um certificado TLS usando o Let’s Encrypt.

Em seguida, verifique se os módulos necessários do Apache estão ativados:

sudo a2enmod rewrite ssl

Depois disso, ative o novo virtual host:

sudo a2ensite mta-sts

Em seguida, execute uma verificação de sintaxe dos arquivos de configuração do Apache, para garantir que não haja erros inesperados:

sudo apachectl configtest

Quando o teste passar sem erros, você pode reiniciar o Apache para ativar completamente o novo virtual host:

sudo service apache2 restart

Agora que o virtual host do Apache foi instalado e configurado, é necessário criar o(s) registro(s) de DNS necessário(s) para permitir que ele seja acessado usando o nome de domínio totalmente qualificado mta-sts.seu-domínio.

A maneira como isso é feito depende do provedor de hospedagem DNS que você usa. No entanto, se você usa a DigitalOcean como seu provedor de DNS, simplesmente navegue até o seu projeto e depois clique em seu domínio.

Por fim, adicione os registros DNS necessários para o subdomínio mta-sts. Se o seu Droplet usa apenas IPv4, crie um registro A para mta-sts, apontando para endereço-ipv4-do-seu-servidor. Se você usa o IPv6 também, crie um registro AAAA apontando para endereço-ipv6-do-seu-servidor.

Neste passo, você criou e configurou um novo virtual host no Apache para o subdomínio MTA-STS e adicionou os registros DNS necessários para permitir que ele seja acessado facilmente. No próximo passo, você adquirirá um certificado Let’s Encrypt confiável para o seu subdomínio MTA-STS.

Passo 3 — Adquirindo um Certificado Let’s Encrypt para seu Subdomínio MTA-STS

Neste passo, você adquirirá um certificado TLS da Let’s Encrypt, para permitir que seu site mta-sts.seu-domínio seja publicado corretamente por HTTPS.

Para fazer isso, você usará o certbot, que você configurou como parte da etapa de pré-requisito Como proteger o Apache com o Let’s Encrypt no Ubuntu 18.04.

Primeiramente, execute o certbot para emitir um certificado para o subdomínio mta-sts usando o método de verificação de plugin do Apache:

sudo certbot --apache -d mta-sts.seu-domínio

Isso emitirá automaticamente um certificado confiável e o instalará no servidor web Apache. Quando o assistente do Certbot perguntar sobre a configuração de um redirecionamento HTTP -> HTTPS, selecione ‘No’, pois isso não é necessário para o MTA-STS.

Para finalizar, teste seu novo virtual host para garantir que ele esteja funcionando corretamente. Use um navegador para visitar https://mta-sts.seu-domínio/.well-known/mta-sts.txt ou use uma ferramenta de linha de comando como o curl:

curl https://mta-sts.seu-domínio/.well-known/mta-sts.txt

Isso mostrará o arquivo de política MTA-STS que você criou na Etapa 1:

Output
version: STSv1
mode: testing
mx: mail1.seu-domínio
mx: mail2.seu-domínio
max_age: 86401

Se ocorrer um erro, verifique se a configuração do virtual host do Passo 2 está correta e se você adicionou um registro DNS para o subdomínio mta-sts.

Neste passo, você emitiu um certificado Let’s Encrypt TLS para o subdomínio mta-sts e testou se ele está funcionando. Em seguida, você definirá alguns registros TXT no DNS para ativar completamente o MTA-STS e o TLSRPT.

Passo 4 — Configurando os Registros DNS Necessários para Ativar o MTA-STS e o TLSRPT

Neste passo, você configurará dois registros TXT no DNS, que habilitarão totalmente a diretiva MTA-STS que você já criou e também habilitarão o TLS Reporting (TLSRPT).

Esses registros DNS podem ser configurados usando qualquer provedor de hospedagem DNS, mas neste exemplo, a DigitalOcean é utilizada como provedor.

Primeiro, faça logon no painel de controle da DigitalOcean e navegue até o seu projeto; depois dê um clique em seu domínio.

Você precisa então, adicionar os dois registros TXT a seguir:

_mta-sts.seu-domínio IN TXT "v=STSv1; id=id-value"
_smtp._tls.seu-domínio IN TXT "v=TLSRPTv1; rua=reporting-address"

id-value é uma string usada para identificar a versão da sua política MTA-STS em vigor. Se você atualizar sua política, precisará também atualizar o valor do id para garantir que a nova versão seja detectada pelos provedores de correio. Recomenda-se usar o carimbo de data atual como o id, por exemplo, 20190811231231 (23:12:31 em 11 de agosto de 2019).

reporting-address é o endereço para onde seus relatórios TLS serão enviados. Pode ser um endereço de e-mail com o prefixo mailto: ou um URI web, por exemplo, para uma API que coleta relatórios. O endereço para o relatório não precisa ser um endereço no seu-domínio. Você pode usar um domínio completamente diferente, se desejar.

Por exemplo, os dois registros de exemplo a seguir são válidos:

_mta-sts.seu-domínio IN TXT "v=STSv1; id=20190811231231"
_smtp._tls.seu-domínio IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@seu-domínio"

Ajuste as variáveis conforme necessário e defina esses registros TXT de DNS em seu painel de controle da DigitalOcean (ou qualquer provedor de DNS que você esteja usando):

Depois que esses registros DNS forem definidos e propagados, o MTA-STS será ativado com a política que você criou no Passo 1 e começará a receber relatórios TLSRPT no endereço que você especificou.

Neste passo, você configurou os registros DNS necessários para que o MTA-STS seja ativado. Em seguida, você receberá e interpretará seu primeiro relatório TLSRPT.

Passo 5 — Interpretando seu Primeiro Relatório TLSRPT

Agora que você ativou o MTA-STS e o TLSRPT (TLS Reporting) para o seu domínio, você começará a receber relatórios de provedores de e-mail suportados. Esses relatórios mostrarão o número de e-mails que foram ou não foram entregues com êxito pelo TLS e os motivos dos erros.

Diferentes provedores de e-mail enviam seus relatórios em momentos diferentes; por exemplo, o Google Mail envia seus relatórios diariamente por volta das 10:00 UTC.

Dependendo de como você configurou o registro DNS TLSRPT no Passo 5, você receberá seus relatórios por e-mail ou por uma API web. Este tutorial se concentra no método de e-mail, pois essa é a configuração mais comum.

Se você acabou de concluir o restante deste tutorial, aguarde até receber seu primeiro relatório e poderá continuar.

Seu relatório diário do TLSRPT por e-mail geralmente possui uma linha de assunto semelhante à seguinte:

Report Domain: seu-domínio Submitter: google.com Report-ID: <2019.08.10T00.00.00Z+seu-domínio@google.com>

Este e-mail terá um anexo no formato .gz, que é um arquivo compactado Gzip, com um nome de arquivo semelhante ao seguinte:

google.com!seu-domínio!1565222400!1565308799!001.json.gz

Para o restante deste tutorial, esse arquivo será chamado de report.json.gz.

Salve esse arquivo na sua máquina local e extraia-o usando a ferramenta que você preferir.

Se você estiver usando um sistema Linux baseado no Debian, poderá executar o comando gzip -d para descompactar o arquivo:

gzip -d report.json.gz

Isso resultará em um arquivo JSON chamado report.json.

Em seguida, você pode visualizar o relatório diretamente como a sequência JSON bruta ou usar seu formatador JSON favorito para colocá-lo em um formato mais legível. Neste exemplo, o jq será usado, mas você também pode usar o json.tool do Python, se desejar.

jq . report.json

Isso produzirá algo semelhante ao seguinte:

Prettified report.json
{
    "organization-name": "Google Inc.",
    "date-range": {
        "start-datetime": "2019-08-10T00:00:00Z",
        "end-datetime": "2019-08-10T23:59:59Z"
    },
    "contact-info": "smtp-tls-reporting@google.com",
    "report-id": "2019-08-10T00:00:00Z_seu-domínio",
    "policies": [
        {
            "policy": {
                "policy-type": "sts",
                "policy-string": [
                    "version: STSv1",
                    "mode: testing",
                    "mx: mail1.seu-domínio",
                    "mx: mail2.seu-domínio",
                    "max_age: 86401"
                ],
                "policy-domain": "seu-domínio"
            },
            "summary": {
                "total-successful-session-count": 230,
                "total-failure-session-count": 0
            }
        }
    ]
}

O relatório mostra o provedor que gerou o relatório e o período do relatório, bem como a política MTA-STS que foi aplicada. No entanto, a seção principal em que você estará interessado é a summary, especificamente as contagens de sessões com êxito e com falha.

Este relatório de exemplo mostra que 230 e-mails foram entregues com êxito por TLS do provedor de e-mail que gerou o relatório e 0 entregas de e-mail falharam ao estabelecer uma conexão TLS adequada.

Caso haja uma falha — por exemplo, se um certificado TLS expirar ou houver um invasor na rede — o motivo da falha será documentado no relatório. Alguns exemplos de motivos de falha são:

• starttls-not-supported: Se o servidor de e-mail de recebimento não suportar STARTTLS.
• certificate-expired: Se um certificado expirou.
• certificate-not-trusted: Se um certificado autoassinado ou outro certificado não confiável for usado.

Neste passo final, você recebeu e interpretou seu primeiro relatório TLSRPT.

Conclusão

Neste artigo, você definiu e configurou o MTA-STS e o TLS Reporting para o seu domínio e interpretou o seu primeiro relatório TLSRPT.

Depois que o MTA-STS estiver ativado e funcionando de maneira estável por um tempo, é recomendável ajustar a política, aumentando o valor de max_age e, eventualmente, alternando-a para o modo enforce quando você tiver certeza de que todos os emails de provedores suportados estão sendo entregue com sucesso por TLS.

Por fim, se você quiser saber mais sobre as especificações MTA-STS e TLSRPT, poderá revisar as RFCs para os dois:

• RFC8461 - SMTP MTA Strict Transport Security (MTA-STS)

• RFC8460 - SMTP TLS Reporting