Enhancing Email Security: Stop Sender Fraud with SPF, DKIM, and DMARC

Não há como filtrar a verdade: Você precisa proteger os e-mails de sua empresa.

Em 2013, mais de 100 bilhões de e-mails comerciais foram enviados e recebidos a cada dia. Apenas um em cada cinco e-mails enviados em 2013 era legítimo, e 92% de todos os e-mails ilegítimos incluíam links para conteúdo potencialmente malicioso.

Existem, no entanto, sinais de melhoria; este mês é o primeiro dos últimos 12 anos em que menos da metade dos e-mails dos clientes da Symantec eram spam.

Pode agradecer a três padrões de segurança de e-mail (e outras iniciativas) pela redução do spam: SPF, DKIM, e DMARC. Ainda assim, os riscos de segurança são prevalecentes. Recentemente me foi contada uma história sobre um CFO que foi sujeito a uma tentativa de phishing. A tentativa falhou, mas se tivesse tido sucesso, teria custado à organização $50.000,

Como para estes padrões de e-mail, ainda há uma grande confusão em torno deles. Eu espero poder dar alguma clareza com este post, assim como orientá-lo sobre como implementar SPF, DKIM e DMARC.

Sender Policy Framework (RFC 4408)

Sender Policy Framework, ou SPF, é o velho homem na parte de autenticação de email. SPF é um padrão aberto que especifica um método para prevenir a falsificação do endereço do remetente, de acordo com o openspf.org. Não se trata de parar o spam; trata-se de controlar e parar tentativas de falsificação do remetente.

SPF permite que você identifique as fontes legítimas de e-mail do seu domínio e evita que fontes não autorizadas enviem milhares – ou mesmo milhões – de e-mails ilícitos do seu domínio.

Existem quatro tipos de abuso de e-mail comumente associados à falsificação de remetente de e-mail:

• Spam (e-mail em massa não solicitado & e-mail comercial não solicitado)
• Fraudsters (419 golpes)
• Malware (adware, zero dias, vírus, trojans, etc.))
• Fishers (spear-phishing)

Você não quer o domínio da sua organização associado a qualquer um destes por razões óbvias. SPF irá ajudar a garantir que os e-mails da sua organização venham realmente de você.

DomainKeys Identified Mail (RFC 6376, substitui a RFC 4871 e RFC 5672 que agora estão obsoletos)

DKIM, ou DomainKeys Identified Mail, é um registro TXT publicado no seu Sistema de Nomes de Domínio (DNS). Ele envolve algo que todos os administradores de TI devem aprender a amar: chaves – chaves públicas para ser específico.

Antes de mergulharmos no DKIM, é importante que entendamos o que são chaves e como elas funcionam. As chaves, neste caso, a criptografia de chaves públicas, consiste em uma chave pública (conhecida por todos) e privada (muitas vezes referida como secreta). As chaves públicas e privadas estão matematicamente ligadas umas às outras, tornando possível uma comunicação segura através de canais públicos.

Estas chaves são como um selo inviolável num envelope transparente. Você não está necessariamente escondendo a mensagem; você só está autenticando com 100% de certeza tanto o remetente quanto a mensagem.

Agora, de volta ao DKIM.

“Tecnicamente o DKIM fornece um método para validar uma identidade de nome de domínio que está associada a uma mensagem através de autenticação criptográfica”, de acordo com dkim.org. Em outras palavras, o DKIM usa chaves para garantir que um remetente de e-mail seja quem diz ser.

Com o DKIM, pares de chaves públicas e privadas são gerados para manter servidores de e-mail e comunicações autenticadas. Cada servidor de saída do Simple Mail Transfer Protocol (SMTP) precisa da chave privada e do prefixo certo para corresponder a um registo DNS público que o servidor de recepção de correio verifica.

Ever porque é que o ícone de bloqueio aparece no Gmail quando recebe mensagens do eBay, Paypal, ou do seu banco? Isso é DKIM e um pouco de DMARC (que iremos cobrir em breve). Abaixo, enviado por correio mostra a correspondência SPF e assinado por mostra a correspondência DKIM. DKIM e DMARC ainda não são essenciais, mas como o IPv6, ele está se movendo rapidamente do laboratório de teste para o melhor-have.

Domain-based Message Authentication, Reporting, and Conformance (RFC 7489)

DMARC, ou Domain-based Message Authentication, Reporting, and Conformance, ajuda remetentes e receptores a trabalharem juntos para criar comunicações de e-mail mais seguras. DMARC foi criado por um grupo de organizações para limitar o abuso baseado em e-mail “resolvendo um par de problemas operacionais, de implantação e de relatórios de longa data relacionados aos protocolos de autenticação de e-mail”, de acordo com dmarc.org.

DMARC permite que o remetente da mensagem indique que suas mensagens estão protegidas com SPF e/ou DKIM. Uma política DMARC aplica instruções claras para o receptor da mensagem a seguir se um e-mail não passar pela autenticação SPF ou DKIM – por exemplo, rejeitá-la ou juntá-la.

Além disso, DMARC envia um relatório de volta para o remetente sobre as mensagens que PASSAR e/ou FALAR a avaliação DMARC.

Como implementar SPF, DKIM, e DMARC

Agora temos um melhor entendimento de cada um desses três padrões (e porque eles são importantes), vamos dar uma olhada em como você pode melhorar a segurança do seu email implementando-os.

Nota: Para o bem deste passo-a-passo, vamos fingir que você é o líder de TI na 301 Moved, uma pequena empresa de web design que usa o Google Apps.

Recentemente, você tem tido alguns problemas com os bots de spam russos. Seus usuários finais têm reclamado sobre o recebimento de notificações de retorno de e-mail de endereços que nunca viram ou para os quais nunca enviaram mensagens. Você percebe que alguém está claramente enviando e-mails fraudulentos do seu domínio.

Então, como você os impede?

Note: Estou incluindo o formato padrão BIND em texto simples e uma captura de tela de como o registro fica no DNS do GoDaddy. No GoDaddy, todos os registos para o domínio de nível superior 301Moved.com utilizam o host “@,” o seu host será provavelmente diferente. Para efeitos deste exercício, vou apenas discutir o correio de saída, não como tratamos estes padrões em relação ao correio de entrada de remetentes externos.

Implementando SPF

Passo Um: o guia do Google para configurar os registros do SPF para trabalhar com o Google Apps é um bom lugar para começar. Seguindo essas instruções, nós adicionamos um novo registro TXT ao nosso DNS Público.

301Moved.com. IN TXT "v=spf1 include:_spf.google.com ~all"

301 Moved também usa Zendesk, um sistema de ticketing que envia e-mails diretamente do seu domínio. Você precisa ter certeza de que nenhum spam está sendo enviado de lá.

Segundo passo: Encontre e adicione o registro SPF do Zendesk.

301Moved.com. IN TXT "v=spf1 include:mail.zendesk.com include:_spf.google.com ~all"

É importante notar que não estamos adicionando um segundo registro SPF, que irá quebrar as coisas; em vez disso, estamos combinando-as em um único registro, tornando-o mais longo à medida que mais remetentes são adicionados.

Nota: Você só pode adicionar um registro SPF por domínio ou subdomínio.

Você também sabe que o 301 Moved tem um antigo gateway de email nas instalações que lida com algumas coisas legadas, então vamos adicionar o bloco IP deles também. 301 Moved usa o mecanismo “IP4” para definir o bloco IP que possui-198.51.100.0/24 (192.51.100.0-254).

Utiliza o SPF Surveyor da Dmarcian para visualizar seus registros SPF.

Passo Três: Adicione endereços IPv4 únicos por conta própria, e blocos de rede na notação Classless Inter-Domain Routing (CIDR). 198.51.100.0 para um único endereço IP (não precisa de um /32) e 198.51.100.0/24 para sub-redes.

301Moved.com. IN TXT "v=spf1 ip4:198.51.100.0/24 include:mail.zendesk.com include:_spf.google.com ~all"

Adicionar o antigo gateway de e-mail garantirá que os e-mails enviados pelo gateway serão autorizados pelo SPF.

Os mecanismos acima são os mais usados, mas há oito no total – incluindo os estranhos e depreciados. Estes mecanismos apenas definem o escopo da partida, não as próprias ações.

As qualificações na próxima seção são onde PASS, SOFTFAIL e FAIL podem ser definidas – uma partida resultaria em uma das três ações (PASS, SOFTFAIL e FAIL) sendo acionada.

• ALL: Se o nome do domínio tiver um registro de endereço (A ou AAAA) que possa ser resolvido para o endereço do remetente, ele será compatível.
• IP4: Se o remetente estiver em um dado intervalo de endereços IPv4, ele será compatível.
• IP6: Se o remetente estiver em um dado intervalo de endereços IPv6, ele será compatível.
• IP6: Se o remetente estiver em um dado intervalo de endereços IPv6, ele será compatível.
• MX: Se o nome do domínio tiver um registro MX resolvendo para o endereço do remetente, ele irá corresponder (ou seja, o e-mail vem de um dos servidores de e-mail de entrada do domínio).
• PTR: Se o nome do domínio (registro PTR) para o endereço do cliente está no domínio dado e esse nome de domínio resolve para o endereço do cliente (DNS reverso confirmado pelo encaminhamento), corresponde. Este mecanismo é depreciado e não deve mais ser usado.
• EXISTS: Se o nome de domínio dado for resolvido para qualquer endereço, ele irá coincidir (não importa o endereço para o qual ele é resolvido). Isto raramente é usado. Junto com a linguagem de macro do SPF ele oferece correspondências mais complexas como DNSBL-queries.
• INCLUDE: Se a política incluída (um nome errado) passar no teste, este mecanismo corresponde. Isto é normalmente usado para incluir políticas de mais de um ISP.

Próximo são os qualificadores. Há milhões de maneiras de combiná-los com uma lista negra e/ou um modelo de lista branca, mas para nossos propósitos aqui, vamos incluir apenas os três mecanismos de busca que mencionamos acima com um único qualificador no final para fazer uma lista branca. Os nossos quatro qualificadores são:

• + para um resultado PASS. Isto pode ser omitido; por exemplo, +mx é o mesmo que mx.
• ? para um resultado NEUTRAL interpretado como NONE (sem política).
• ~ (til) para SOFTFAIL, uma ajuda de depuração entre NEUTRAL e FAIL. Tipicamente, mensagens que retornam um SOFTFAIL são aceitas mas etiquetadas.
• – (menos) para FAIL, o e-mail deve ser rejeitado (veja abaixo).

Passo Quatro: Aplique a política SOFTFAIL.

Por enquanto, 301 Moved usa o til para SOFTFAIL. Usando o til, todos os e-mails que não correspondam ao Google, Zendesk ou o bloco IP mencionado seria o SOFTFAIL. O e-mail ainda será entregue, mas provavelmente será enviado para a pasta Spam ou Junk. No entanto, isto é inteiramente da responsabilidade do servidor de e-mail do destinatário. Não é definido por nenhum padrão.

A “-“. (menos) nesta situação, o correio não corresponderia inteiramente à correspondência (e provavelmente saltaria). Você pode inverter isso assim que começar a ter mais visibilidade no seu correio de saída (espere pelo DMARC), e assim que se sentir mais confortável com sua infra-estrutura de correio.

SPF é ótimo porque não há modificação dos próprios mailservers. Os cabeçalhos permanecem os mesmos. Apenas um simples registro TXT (o tipo de registro SPF atual e dedicado nunca foi tão popular e agora é depreciado) e você pode instruir a maioria dos servidores de e-mail do mundo que devem estar piscando seu nome por aí.

No final do dia, o servidor SMTP receptor verifica o IP do remetente em relação ao registro SPF que ele consultou, ele então aplica a política baseada nas suas instruções. Em outras palavras, você está se autorizando, e seus provedores, a enviar (principalmente) emails confiáveis porque você está publicando uma lista de controle de acesso (ACL) para o público.

No entanto, mensagens ainda podem ser modificadas em trânsito, e falsificadores e phishers astutos podem se esgueirar pelo SPF de algumas maneiras interessantes (talvez um tópico para outro dia). É SMTP: TLS de ponta a ponta não é garantido, então devemos sempre assumir o cleartext. As mensagens podem ser adulteradas ou forjadas.

But enter stage right…

Implementing DomainKeys Identified Mail

Quando o mail é enviado, 301Moved.com assina (sem encriptar) mail com a chave privada. A partir de agora, qualquer modificação na mensagem, incluindo corpo, cabeçalhos ou anexos, quebrará a assinatura e tornará a mensagem inválida. Novamente, nós olhamos para o Google, usando seu artigo Authenticate email com DKIM

Step Five: Adicione a chave pública ao seu registo DNS.

google._domainkey.301Moved.com IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCsC1iZ3D7AR3FrKtBYfnoKztCGgExFIReC0b1MPY1rpGZa9aTBYq7cDV6F8lzDVr8/K+z9Xt1gUV4P7tT8wuwgacR4oqiAWaUprbnINAxinJr4ohB1TIW3diX2fEA2t5kyUGCGziJFlHicZyJbk5QEaVLcSFD4V8R9f0Voz4P4jQIDAQAB"

Cada registo DKIM tem um prefixo selector único, o que significa que podemos publicar mais do que um. Em vez de os combinar num único registo, como fizemos com o SPF, pode usar selectores únicos e publicar tantas chaves públicas quantas precisar. Isto permite-nos adicionar um grande número de servidores autorizados DKIM sem qualquer limite superior.

Vai notar que o prefixo acima é “google”, o padrão que o Google Apps usa ao gerar um registro DKIM para que você publique. Você pode alterar isso no Google, e na maioria das outras configurações, então se você queria o prefixo “dkimawesome”, nada o impede.

Alguns provedores de nuvens fazem isso de forma diferente. Em vez de gerar pares de chaves únicas para cada locatário da nuvem, eles assinam todos os e-mails enviados para todos os domínios com a mesma chave – enquanto você publica um Canonical Name (CNAME) em vez da chave deles.

Zendesk faz isso, nós CNAME duas chaves diferentes no nosso DNS para o DNS deles. O Zendesk tem uma grande ajuda – Assine digitalmente o seu e-mail com DKIM ou DMARC (Plus e Enterprise)

Step Six (se aplicável): CNAME as chaves no seu DNS para o DNS deles. Qualquer consulta DNS procurando por zendesk1._domainkey.301Moved.com será redirecionado pelo seu DNS para zendesk1._domainkey.zendesk.com. O Zendesk então serve as chaves DKIM diretamente.

zendesk1._domainkey.301Moved.com IN CNAME zendesk1._domainkey.zendesk.comzendesk2._domainkey.301Moved.com IN CNAME zendesk2._domainkey.zendesk.com

Pode ver o que isto parece para outros servidores usando a ferramenta nslookup (para Unix ou Windows) localmente.

Não todos os remetentes de saída suportam DKIM. O Google Apps obviamente suporta, mas seus servidores de e-mail antigos não podem.

Implementing Domain-based Message Authentication, Reporting, and Conformance

DMARC, ou Domain-based Message Authentication, Reporting, and Conformance, é a ferramenta final que temos para combater e-mails maliciosos. Para servidores de e-mail que ouvem, DMARC, relés como tratar SPF e DKIM, bem como como reportar de volta para você, dando-lhe a tão necessária visibilidade em suas taxas de entrega e conformidade de registro.

E sim, DMARC é outro registro TXT.

Step Seven: Configure uma política DMARC, identifique o endereço mailto, configure o modo de alinhamento e identifique a percentagem de mensagens a que a política deve ser aplicada (não se preocupe, isto é mais simples do que parece).

301Moved.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r; pct=100; sp=none"

A política acima é designada como p=nenhuma. Nós não estamos modificando o fluxo de e-mails, ainda que seja simples configurar a política e é um relatório relevante. O endereço para o qual os relatórios XML do status DMARC serão enviados é designado com rua=.

Servidores de email receptores enviarão anexos XML mostrando como as mensagens de – e aquelas que afirmam ser de – seu domínio serão empilhadas contra o SPF, DKIM e DMARC que a maioria dos servidores de email modernos impõe.

Estes relatórios mostram, por envelope, se o SPF passou, falhou ou falhou. Eles mostram se o DKIM falhou, falhou no alinhamento ou teve sucesso – e como as políticas acima foram aplicadas.

Por último, estes relatórios mostram a disposição final de entrega da mensagem. Existem algumas grandes ferramentas para ajudá-lo a analisá-las. Mesmo que você não esteja aplicando políticas às mensagens, é como firewall, DNS e logs IDS/IPS – é sempre bom ter algo que você pode voltar e olhar para.

O adkim=r especifica o modo de alinhamento DKIM relaxado, “r” é para relaxado e “s” é para estrito. O modo relaxado permite domínios DKIM d= autenticados dentro de um Domínio Organizacional comum no cabeçalho do e-mail – de: endereço a PASSAR a verificação DMARC. O modo estrito requer uma correspondência perfeita entre o domínio DKIM d= e o cabeçalho de um e-mail – do endereço. Pense em subdomínios, se os usar.

aspf=r faz exactamente a mesma coisa, excepto para verificações SPF.

O pct=100 é a percentagem de mensagens que são realmente tratadas para a política DKIM. Escolhido aleatoriamente, o servidor de email de recepção irá impor a política sobre esta percentagem de mensagens do seu domínio. Estamos usando 100 por enquanto porque não estamos aplicando uma política, ainda.

Antes de aplicarmos uma política, vamos reduzir isso para cinco, para que apenas uma em cada 20 mensagens tenha a política aplicada à medida que viramos a bandeira p= da política para quarentena ou rejeição. Desta forma, se lixarmos totalmente 95% do nosso e-mail ainda será entregue, em vez de 0% entregue se começarmos em pct=100.

Mensagens falhando a verificação DMARC, ou seus modos de alinhamento adkim= e aspf= que definimos acima são então suaves bounced, como acima, para uma política de quarentena, ou bounced inteiramente quando definido para rejeitar.

É muito importante notar que o DMARC passará a mensagem se SPF ou DKIM passarem, e só FALHE a mensagem se ambos SPF e DKIM falharem. Dessa forma, mensagens somente SPF e somente DKIM podem PASSAR DMARC, mas mensagens sem qualquer SPF/DKIM sempre irão FALAR. Essa é uma ótima notícia se você tiver sistemas de e-mail que suportam apenas SPF, ou apenas DKIM.

Utilize o Inspetor DMARC da Dmarcian para verificar os seus registros DMARC.

Dmarcian é uma ferramenta paga que lhe permite gerir facilmente os seus relatórios DMARC, existem muitos outros, mas Dmarcian é o meu favorito.

Update: Recebemos alguns e-mails (compatíveis com DMARC!) a perguntar sobre a política de subdomínios sp=none. Com uma política que inclui sp=none, você não está especificando uma política DMARC para nenhum subdomínio. Isso é feito manualmente, definindo um registro DMARC apropriado para cada subdomínio específico ou incluído no registro DMARC principal com um sp=quarantine ou sp=reject.

Configuração mínima

Se você quiser experimentar isto, eu recomendo que você comece muito aberto e permaneça simples até que você tenha relatórios DMARC suficientes para começar a aplicar qualquer coisa.

301Moved.com. IN TXT "v=spf1 ip4:198.51.100.0/24 include:mail.zendesk.com include:_spf.google.com MX ?all"

Definir grandes provedores com um “include:” e qualquer bloco IP de onde você possa enviar e-mail com um “IP4 “ou “IP6”. Use “MX” para autorizar os seus servidores de entrada de correio. E a menos que você envie e-mail diretamente da mesma caixa/servidor que hospeda seu site (mau, má prática, a propósito) você pode pular o mecanismo “A” que foi mencionado acima. O “?” não aplica nenhuma política às suas mensagens, mas obtém o seu registo SPF para que o DMARC o reconheça.

google._domainkey.301Moved.com IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCsC1iZ3D7AR3FrKtBYfnoKztCGgExFIReC0b1MPY1rpGZa9aTBYq7cDV6F8lzDVr8/K+z9Xt1gUV4P7tT8wuwgacR4oqiAWaUprbnINAxinJr4ohB1TIW3diX2fEA2t5kyUGCGziJFlHicZyJbk5QEaVLcSFD4V8R9f0Voz4P4jQIDAQAB"

Apanhe o selector correcto, “google” neste caso, e a chave certa. Lembre-se, você pode publicar mais de uma.

Nota: Por favor não publique esta chave real ou eu serei capaz de DKIM-assine seu e-mail.

301Moved.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r; pct=5; sp=none"

Para DMARC, nós não temos nenhuma política aplicada, estamos em modo relaxado, mas estamos pedindo que os relatórios XML sejam enviados para uma caixa de correio que podemos acessar. A partir daí, DMARC nos dá um feedback bastante rápido (não em tempo real) sobre como podemos restringir as diferentes políticas nos três registros.

Mas espere, E sobre TLS?

Transport Layer Security, ou TLS, não faz parte do padrão DMARC, e não é um registro DNS.

Em vez disso, TLS é apenas um Secure Socket Layer (SSL) adulto que os servidores de e-mail podem usar para enviar mensagens uns aos outros através de conexões públicas. É SMTP envolvido em TLS, como se você pudesse fazer muitas outras coisas dentro/sobre TLS-SNMP sobre TLS e FTP sobre TLS sendo exemplos comuns. TLS somente encripta mensagens em trânsito, não em repouso.

Se enviarmos uma mensagem com assinatura DKIM sobre TLS, ela é assinada por toda a sua vida, mas somente encriptada enquanto salta do seu Google Apps para o seu Cisco Ironport, ou para onde quer que o seu email transita. TLS certamente não protege mensagens em repouso, embora também seja usado para sua sessão HTTPS:// para webmail já que você está lendo essa mesma mensagem, mas novamente, isso está em trânsito.

TLS é algo que você deve usar sempre que possível, mas também estar pronto para falar cleartext para outros sistemas de correio público. Mesmo em 2015 alguns servidores de e-mail não suportam STARTTLS (serverspeak para iniciar o aperto de mão TLS).

Você pode impor o uso de TLS com certos domínios externos no Google Apps com uma simples mudança de configuração. É uma boa coisa ligar para empresas externas associadas, parceiros e outras organizações, mas só se pode aplicar o TLS quando tiver a certeza de que é confiável e suportado por todos os servidores de e-mail naquele domínio específico.

A Importância da Segurança de E-mail e Evitar Fraudes do Remetente

Se você for um administrador de TI veterano ou apenas começando, estes três padrões têm a mesma importância. É certo que o que cada um deles faz e como trabalham juntos pode ficar um pouco desorganizado, mas implementá-los é relativamente simples – e os benefícios valem bem o seu tempo.