Falar sobre segurança no quesito de e-mails é sempre bem difícil, temos diversos apontamentos que são configurados de forma rotineira, os mais utilizados no dia a dia de um administrador de DNS são os Tipos, A, CNAME, PTR, etc…

No entando quando estamos ajustando configurações que dizem respeito a segurança no tráfego de e-mails devemos ter muito cuidado e conhecimento no que estamos fazendo.

Atualmente os maiores serviços de e-mails como Gmail, Outlook, Hotmail, Globo, Uol e outros, podem recusar seus e-mails, mesmo validos e autênticos se houver alguma configuração de DNS incorreta.

Para evitar um desastre desses devemos se ater as boas práticas de segurança para gestão de nomes para correio. (isso vale para qualquer tipo de tecnologia, Exchange, Zimbra, Lotus…)

A partir de agora vamos iniciar um estudo que vai abordar a principal arma que um administrador de correio pode usar para proteger todo o sistema de mensageiria, que são as boas praticas para segurança da informação.

A Trindade

Exemplo de utilização Dmarc, SPF e DKIM

Quando falamos sobre segurança, principalmente no que diz respeito a AUTENTICIDADE, temos que abordar a Trindade, ou o Tri pé, de segurança para correio que são as configurações de DNS: SPF/DKIM/DMARC. Além de alinhar seu domínio com as melhores práticas de segurança, eles fornecem garantias que diminuem fortemente ataques do tipo Phinhing/Scam. (Aleluia!)

Nem tudo são Rosas…

A cada dia que passa eu me convenço que menos os administradores entendem sobre a trindade de segurança para o serviço de correio, a falta de conhecimento é um grande problema para adoção de boas práticas de segurança da informação.

Para entendermos melhor vamos falar agora sobre cada um desses registros que compõem a trindade, vamos iniciar com o SPF:

O que é o protocolo SPF (Sender Policy Framework) ? 

Definido para RFC 7208 e capaz de combater a falsificação do domínio e o retorno de e-mails (return-path).

De acordo com o Internet Engineering Task Force (IETF) o SPF se Baseia no DNS do seu nome de domínio e permite atestar que o IP do emissor tem todos os direitos possíveis para enviar e-mails, desta forma se um outro IP tentar enviar e-mails em nome do seu domínio sem ter autorização o domínio remoto pode identificar a ausência do registro neste domínio e não aceitar esses e-mails, que provavelmente devem ser falsos.  

O SPF é altamente eficaz contra ataques de Phishing.

O SPF Permite

  • Que seja publicado pelo administrador do Domínio uma política onde são configurados os endereços das maquinas autorizadas a enviar mensagens em nome desse domínio.
  • Permite aos administradores estabelecer critérios de aceitação de mensagens devido a checagem do SPF dos domínios remotos, por exemplo, recusar mensagens de domínios sem SPF configurado.

Como Funciona?

O Funcionamento é simples e eficaz, vamos usar como exemplo o meu domínio CHESLEY.COM.BR, onde eu desejo enviar e-mails apenas com meu MX, neste caso eu devo criar um registro no DNS EXTERNO tipo TXT da seguinte forma:

Chesley.com.br.  IN TXT “v=spf1 mx -all”

Não é anormal que eu deseje que outros domínios também sejam autorizados a enviar meus e-mails, suponhamos que você necessite que uma empresa envie e-mails em seu nome, nome do seu domínio, para campanhas publicitarias, neste caso a configuração do registro sofre uma pequena alteração:

Chesley.com.br.   IN TXT “v=spf1 mx include:smtp.terceiros.com.br -all”

Notem que acrescentamos a sentença “Include:smtp.terceiros.com.br” lembrando que “smtp.terceiros.com.br” é o domínio que eu desejo que envie e-mails.

Ao utilizar cláusula “-all” diz que devem ser recusados (“-“, prefixo Fail) e-mails partindo de qualquer outro endereço IP (all).

Todas as opções de prefixos são:

“+” Pass
“?” Neutral
“-” Fail
“~” SoftFail

O prefixo é opcional (Mas, não deixe de usar), e se omitido o valor utilizado é o “+” (Pass), isso é ruim!

A cláusula “all” deve ser sempre a cláusula mais à direita, geralmente a última a ser configurada.

Ela define qual resposta será retornada em uma consulta SPF, caso nenhuma das outras cláusulas se aplique.

Para informações completas sobre a assinatura SPF, consulte RFC7208 . 

DKIM (Domain Keys Identified Mail)   

DKIM é uma especificação do IETF, definido na RFC 6376, que define um mecanismo para autenticação de e-mail baseado em criptografia de chaves públicas.

Ao utilizar o DKIM a organização assina digitalmente as mensagens que são enviadas, ou seja, cada e-mail enviado leva consigo a digital da organização! Desta forma o receptor pode confirmar a autenticidade da mensagem por meio da assinatura digital como a consultar e feita por par de criptografia a chave publica é obtida por meio de consulta ao DNS do domínio assinante.

Como Dkim verifica o cabeçalho da mensagem, o que difere do SPF que verifica apenas o envelope! Essa técnica pode acarretar um maior uso dos MTAs (são seus servidores de e-mail, acreditem, muitos não sabem o que é um MTA) ao implementar DKIM fique de olho no gerencialmente de memória e processamento dos servidores OK?

Como Implementar?

A implementação difere de cada sistema, por exemplo o OpenSSL pode ser usado, ou ainda alguma ferramenta de terceiros! Na verdade, cada sistema difere em si, o site DKIM Core é uma grande ferramenta on-line onde você  pode informar o e-mail e ele gera automaticamente uma chave privada, para o próprio servidor de e-mails, e um registro TXT para incluirmos no DNS Autoritativo do domínio.

Neste exemplo foi gerado a chave privada e o registro para ser posto no DNS.

Exemplo de DKIM DNS record

Um exemplo do registro DNS DKIM completo para chesley.com.br é:

1579919567.chesley._domainkey.chesley.com.br. IN TXT (      “v=DKIM1;t=s;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCvmSaYUujWAOSthlfLyMaEzRqX”       “d0wMxlcozUCvIfYZ2HnbRGNxrYtv5jTLEBKnC3w2jztvl+aBSiQ+0MqjghZAxFey”        “MgbEJ4Wzb7i0AvXQhzvz7wGiBuRmAkrF3USCkWx4rbbPhCH1qCSdKbxCt08RhgWu”

O seletor (s=): 1579919567.chesley

  • O domínio (d=): chesley.com.br
  • A versão (v=): DKIM1

A chave pública (p=): MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCvmSaYUujWAOSthlfLyMaEzRqXd0wMxlcozUCvIfYZ2HnbRGNxrYtv5jTLEBKnC3w2jztvl+aBSiQ+0MqjghZAxFeyMgbEJ4Wzb7i0AvXQhzvz7wGiBuRmAkrF3USCkWx4rbbPhCH1qCSdKbxCt08RhgWu2DnQhSsn/8+eu3wY6w

Tag obrigatória

  • p= é a chave pública usada por um provedor de mailbox para corresponder à assinatura DKIM gerada usando a chave privada

Tags opcionais recomendadas

  1. v= é a versão do registro. O valor deve ser DKIM1 e ser a primeira tag no registro DNS, conforme mostrado no exemplo.
  2. t= indica que o domínio está testando o DKIM ou está impondo uma correspondência de domínio no cabeçalho da assinatura entre as tags “i=” e “d=”, alguns domínios não aceitam a tag de teste.
  3. t=y indica que o domínio está testando DKIM, utilize essa tag apenas em teste, quando for implementar retire, alguns domínios não aceitam DKIM para teste; portanto, essa tag deve ser excluída antes da implantação completa ou alterada para t=s se estiver usando a tag “i=” no cabeçalho da assinatura DKIM.
  4. t=s indica que qualquer cabeçalho de assinatura DKIM usando a tag “i=” deve ter o mesmo valor de domínio no lado direito do sinal @ na tag “i=” e na tag “d=” (i= local-part@domain.com). O domínio da tag “i=”  não pode ser um subdomínio da tag “d=”. Não inclua esta tag se for necessário o uso de um subdomínio.

Para informações completas sobre a assinatura DKIM, consulte o site DKIM ou RFC 6376.

DMARC – Porque é tão importante?

               DMARC é regido pela RFC 7492, definida pela IETF como “Domain-based Message Authentication, Reporting, and Conformance (DMARC)” traduzida literalmente seria “Mensagem Baseada em Domínio de Autenticação, Relatório e Conformidade”.  Sua proposta é de normatizar e garantir a autenticação no envio de e-mails, muitos provedores de escala mundial como Google e Microsoft tem baseado suas políticas de reputação de domínios na adoção ou não do DMARC. 

Antes de configurar DMARC é necessário saber que trata-se de um conjunto de regras que depende também do receptor da mensagem, é um conjunto de regras que permite a coordenação dos esforços mútuos na detecção e tratamentos de e-mails possivelmente fraudulentos.  

Funciona da seguinte forma, os remetentes publicam uma politica que desejam que os receptores sigam, para isso é envio relatórios aos remetentes contendo quantidade de e-mails falsos que foi detectado e rejeitado.  

O destinatário que utiliza DMARC verifica tanto o SPF como o DKIM e assim pode determinar quem é o verdadeiro remetendo do e-mail, logo em seguida é aplicada a política definida para o domínio 

Desta forma, em um trabalho conjunto, emissor e receptor trabalham juntos na prevenção de e-mails falsos.

Como Implementar?

Para implementar pode-se utilizar o site DMARC Guide, que testa o seu domínio pra ver se já há um registro SPF, DKIM e DMARC, orientando no processo.

Quando testamos o nosso domínio chesley.com.br, o resultado é similar ao que encontra-se abaixo:

Ao seguir com a implementação as politicas escolhidas gerarão o registro TXT para ser implementado em seu DNS AUTORITATIVO, conforme exemplo:

_dmarc.chesley.com.br. IN TXT “v=DMARC1; p=reject; rua=mailto:chesley@chesley.com.br; ruf=mailto:chesley@chesley.com.br; sp=reject; ri=86400”

Resumindo os campos do registro:

V: É o nome do registro, como DMARC1, por exemplo.

P:  Aqui é definido a ação que deve ocorrer com seus e-mails, os e-mails podem ser rejeitados, colocados em quarentena ou ainda nada ser feito. Neste exemplo defini para que os e-mails sejam rejeitados se eles não estiverem obedecendo os critérios de aceitação e autenticação do domínio.

Rua/Ruf: Aqui é definido o envio de relatórios para quaisquer falhas detectadas, RUA é o relatório mais geral, mais superficial, RUF é o relatório ais completo, geralmente usado para analises mais sofisticadas.

Recomendo que tenha uma caixa de correio que possa receber grandes volumes para aplicar o RUF.

Para informações completas sobre a assinatura DMARC, consulte a RFC 7489.

Conclusão

Acredito que neste post eu falei o que muitos perguntam mais nunca encontram uma resposta direta, a segurança no quesito de e-mails e basicamente saber utilizar os recursos de DNS de forma correta, não adianta confiar apenas no AntiSpam! As fraudes para ambientes de correios se baseiam principalmente no sequestro da identidade, quebrando assim toda autenticidade que o domínio possa ter.

Desta forma conhecer e aplicar o Tripé da segurança para ambientes de correios é uma obrigação por parte do administrador, lembrando que a política de segurança da informação para correio independe da tecnologia utilizada.

Ao utilizar as politicas de segurança para DNS, SPF, DKIM e DMARC, temos um cenário corporativo mais seguro para todos, onde os domínios são investigados e o trafego de mensagens de e-mails se torna mais seguro e mais completo.

Na próxima postagem estaremos falando sobre Conectores, de forma mais abrangente trabalharemos com a arquitetura de cada um e seus efeitos em uma estrutura de e-mail Exchange Server.