Segurança no seu sistema de email: SPF, DKIM, DMARC

0 Likes 40 Views
Referente a Cibersegurança Tagged , , ,

O sistema de e-mail sempre teve problemas de segurança e, infelizmente, simplesmente criptografar transferências de mensagens entre servidores de e-mail não é suficiente para impedir spammers e outros remetentes de e-mail indesejados. Golpes de phishing, spam e spoofing de e-mail dependem de técnicas que forjam mensagens para fazê-las parecer que se originaram num remetente legítimo. A chave para reduzir e-mails indesejados e maliciosos é usar técnicas para validar que um e-mail tem origem num remetente autorizado e que o próprio e-mail não foi modificado em trânsito.

O Simple Mail Transfer Protocol (SMTP), um protocolo usado para transmitir mensagens de e-mail, foi publicado pela primeira vez em 1982 sem nenhuma preocupação com a segurança do e-mail. A expectativa era que a segurança eventualmente fosse abordada por algum outro mecanismo. O tráfego SMTP entre servidores de e-mail agora pode ser criptografado e autenticado usando o protocolo TLS. No entanto, foi deixado de fora do protocolo original qualquer consideração sobre como autenticar o e-mail. Como o e-mail continua a atuar como um vetor primário para ameaças de segurança cibernética de todos os tipos, três protocolos principais de autenticação e validação de e-mail foram desenvolvidos para combater a enxurrada de spam, phishing e spoofing de e-mail:

  • Sender Policy Framework (SPF) – define um processo para descobrir se um servidor de e-mail está autorizado a entregar e-mails para um domínio de envio no DNS.
  • DomainKeys Identified Mail (DKIM) – define um processo para assinar e autenticar digitalmente mensagens de e-mail como vindas de um servidor de e-mail autorizado a enviar e-mails para o domínio de origem. Assinaturas DKIM permitem que provedores de e-mail autentiquem em nome dos proprietários do domínio de e-mail.
  • Domain-based Message Authentication, Reporting and Conformance (DMARC) – define um processo para descobrir a resposta apropriada ao recebimento de um e-mail que não consegue autenticar usando SPF (servidor de e-mail não autorizado) ou DKIM (assinatura digital falha ao autenticar).

Implementar um protocolo totalmente novo para abordar a segurança num protocolo como o SMTP depois de ele estar amplamente adotado não é desejável nem prático. Como resultado, os padrões da Internet para métodos de validação e autenticação de e-mail dependem de protocolos existentes. Para autenticação de e-mail, isso significa usar DNS para distribuir as informações necessárias para validar e-mails de um determinado domínio. Isso é feito em parte porque é mais simples confiar em protocolos e infraestrutura existentes e porque pode ajudar a reduzir o impacto na taxa de entrega de e-mail. Os seguintes protocolos de validação publicam suas informações de autenticação e autorização no DNS:

  • O SPF usa o DNS para publicar os domínios, subdomínios e servidores de e-mail dos quais e-mails autorizados podem ser enviados.
  • O DKIM usa o DNS para anunciar as chaves públicas que podem ser usadas para autenticar mensagens de e-mail como tendo se originado legitimamente do domínio.
  • O DMARC usa o DNS para anunciar as políticas que devem ser aplicadas a e-mails que não conseguem autenticar com o SPF, DKIM ou ambos.

O uso do SPF, DKIM e DMARC requer um software de servidor de e-mail que suporte os protocolos. A configuração depende do caso de uso, mas os dados do SPF, DKIM e DMARC são armazenados em registos DNS TXT. A configuração pode ser amplamente concluída criando registos DNS para o domínio ou subdomínio do qual o e-mail será enviado.

 

O que é SPF ?

O protocolo SPF está definido no RFC 7208, Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Versão 1, publicado em 2014. O SMTP não impede que os servidores de e-mail usem qualquer domínio como fonte de mensagens; o SPF foi criado para resolver esse problema. O SPF define um processo para que os proprietários de domínios identifiquem os endereços IP e os domínios autorizados a serem utilizados como fonte de mensagens de correio eletrónico enviadas a partir do domínio. Quando o SPF é utilizado, o spam pode ser reduzido e as mensagens de phishing de domínios falsificados podem ser assinaladas e rejeitadas com base no domínio incluído no endereço do remetente do e-mail.

Um registo SPF é um registo DNS TXT de uma linha que contém os endereços IP dos servidores de correio eletrónico autorizados e o domínio ou subdomínio para o qual esses servidores estão autorizados a enviar correio eletrónico. Os servidores de correio com suporte de SPF que recebem mensagens que parecem ter sido enviadas de um domínio que utiliza SPF têm de efetuar uma pesquisa de DNS para o registo DNS TXT SPF que contém a lista de fontes de correio eletrónico autorizadas.

As sete respostas válidas a uma consulta de verificação SPF são as seguintes:

  1. Pass –  significa que o servidor de correio de envio está autorizado a enviar correio para o domínio.
  2. Fail –  significa que o servidor de correio de envio não está autorizado a enviar correio para o domínio. Por vezes é designado por falha grave para diferenciar da falha suave.
  3. None –  significa que não foi encontrado qualquer registo SPF para o domínio em questão.
  4. Neutral –  é devolvido quando o proprietário do domínio tem um registo SPF no sistema DNS que não afirma explicitamente quaisquer endereços IP ou domínios autorizados. Os destinatários podem interpretar este resultado como uma aprovação ou uma reprovação, dependendo da configuração DMARC para o domínio.
  5. Soft fail –  significa que o anfitrião remetente provavelmente não está autorizado a enviar correio eletrónico para o domínio. Dependendo da configuração DMARC e do servidor de correio eletrónico recetor, este resultado pode ser tratado como aprovado ou reprovado.
  6. Temporary error – significa que a consulta falhou devido a uma condição de erro temporária, como um tempo limite do DNS. Depois de receber um erro temporário, o servidor de correio recetor termina a sua troca SMTP com o remetente e a entrega dessa mensagem é atrasada.
  7. Permanent error – significa que o registo SPF não pôde ser corretamente processado e a mensagem não foi entregue. Este tipo de erro pode ocorrer se existir mais do que um registo SPF para o domínio de envio ou se o registo SPF tiver erros de sintaxe.

Não é obrigatório implementar o DKIM e o DMARC para que o SPF funcione, mas eles funcionam melhor juntos. Por exemplo, o DMARC fornece a funcionalidade extra para orientar os destinatários sobre a rejeição ou aceitação de mensagens que falham o SPF de alguma forma.

O que é o DKIM ?

O protocolo DKIM é definido no RFC 6376, DomainKeys Identified Mail (DKIM) Signatures, publicado em 2011. Ele define um mecanismo para o remetente de e-mail reivindicar a responsabilidade pelas mensagens vinculando esse domínio às mensagens usando assinaturas digitais. As assinaturas de mensagens DKIM são incorporadas em cabeçalhos de mensagens personalizados que estão em conformidade com o padrão da Internet para sintaxe de mensagens. Isso significa que qualquer implementação de servidor SMTP que suporte DKIM processa automaticamente mensagens com assinaturas DKIM no cabeçalho do e-mail, tentando autenticar a assinatura. A autenticação DKIM permite que os proprietários de domínio especifiquem diferentes chaves de assinatura para uso por diferentes provedores de serviços de e-mail. Elas podem ser internas à organização remetente — ou seja, e-mails enviados de filiais ou subsidiárias remotas — ou podem ser usadas por provedores de serviços de e-mail comerciais para enviar e-mails em nome do proprietário do domínio. Em qualquer caso, as chaves privadas dos pares de chaves públicas DKIM são mantidas com segurança por quem controla os servidores de e-mail. As chaves públicas são publicadas no DNS; qualquer pessoa que receba e-mails do domínio pode encontrá-las facilmente.

O que é o DMARC ?

O protocolo DMARC é definido no RFC 7489, Domain-based Message Authentication, Reporting, and Conformance (DMARC), publicado em 2015. Com o DMARC, o proprietário de um domínio pode especificar as ações a serem tomadas quando um servidor receptor não consegue autenticar uma mensagem. Remetentes de e-mail que usam SPF e DKIM podem beneficiar desses protocolos sem implementar o DMARC. O destinatário, no entanto, deve decidir como lidar com mensagens que podem não ter tido origem num remetente autorizado ou que não conseguem autenticar uma assinatura digital. Quando SPF e DKIM são usados ​​com DMARC, o proprietário do domínio pode solicitar feedback na forma de relatórios forenses sobre mensagens individuais que falharam na autenticação ou em relatórios agregados que resumem todas as mensagens que falharam em SPF, DKIM ou ambos. O DMARC permite que o proprietário do domínio crie uma política de segurança de e-mail que ajude os destinatários a evitar e-mails falsificados ou outros e-mails não autorizados e que ajude o proprietário do domínio a sinalizar quando possiveis hackers estão a atacar o domínio.

As políticas DMARC incluem o seguinte:

  1. None – significa que nenhuma ação é necessária relacionada à mensagem – ela pode ser entregue como legítima. Esta política fornece ao proprietário do domínio um método de registar informações sobre a frequência com que a política foi invocada e é geralmente usada ao implementar o DMARC pela primeira vez.
  2. Quarantine – significa que a mensagem pode ser suspeita. Ela pode ser entregue, mas deve ser roteada para uma pasta apropriada — por exemplo, a pasta de lixo eletrônico ou spam do destinatário.
  3. Reject – significa que a mensagem definitivamente não é autorizada e não deve ser entregue.

Os registos DMARC, armazenados em registos DNS TXT, contêm informações adicionais sobre como as políticas devem ser aplicadas, bem como especificam que tipo de relatórios são esperados e para onde devem ser enviados.

Contexto / Cenário

A empresa “Empresa1” tem um sistema de email implementado para os seus funcionários, mas recebem demasiado spam e tentativas de phishing, ao mesmo tempo que os emails enviados pelos seus utilizadores vão muitas vezes parar á pasta SPAM dos destinatários, dando a sensação aos mesmos que a “Empresa1” não tem o seu email bem protegido / configurado, o que prejudica a sua reputação junto dos seus parceiros, clientes e fornecedores. A existência de mecanismos como SPF, DKIM e DMARC não está documentada.

Riscos

1. Aumento do risco de spoofing

  • Sem SPF, DKIM e DMARC, um atacante pode forjar e-mails usando o seu domínio (spoofing) para enganar destinatários. Isso pode ser usado em ataques como phishing, espalhar malware ou solicitar informações confidenciais.

2. Perda de credibilidade do domínio

  • Se e-mails fraudulentos forem enviados em nome da sua empresa, clientes, parceiros ou fornecedores podem perder a confiança no seu domínio. Isso pode impactar negativamente sua reputação no mercado.

3. Problemas com entregabilidade de e-mails

  • Provedores de e-mail como Gmail, Outlook e Yahoo priorizam e-mails autenticados. Sem SPF, DKIM e DMARC, as suas mensagens legítimas podem ser marcadas como spam ou rejeitadas.

4. Aumento da vulnerabilidade a ataques

  • A falta de autenticação permite que hackers explorem o domínio para campanhas de engenharia social, comprometendo dados de clientes, colaboradores ou parceiros.

5. Falta de visibilidade e controle

  • Sem DMARC configurado, não é possível recebe relatórios sobre o uso do seu domínio em e-mails, dificultando a identificação de abusos ou padrões suspeitos.

6. Potenciais implicações legais

  • Em alguns setores, existem regulamentações que exigem medidas adequadas de segurança de e-mail. A ausência de autenticação pode expor sua empresa a sanções ou multas em caso de incidentes.

Para empresas que são certificadas com a ISO:27001, ou que estejam em preparação para a certificação, ter em consideração que a segurança do sistema de e-mail faz parte desta framework de segurança, nomeadamente no controlo 8.12 Data leakage prevention

8.12 Data leakage prevention

Control – Data leakage prevention measures should be applied to systems, networks and any other devices that process, store or transmit sensitive information.
Purpose – To detect and prevent the unauthorized disclosure and extraction of information by individuals or systems.

…

  • c) acting to prevent information from leaking (e.g. quarantine emails containing sensitive information).

Soluções / Mitigações

  1. Verificar qual o estado do uso de mecanismos como SPF, DKIm e DMARC. Para o efeito pode-se consultar o site MXToolbox -> Email health. Colocando o nosso dominio, podemos obter um relatorio completo do estado dos diferentes mecanismos referidos anteriormente.
  2. Configurar uma entrada SPF no nosso dominio.
    1. Aceder ás configurações do dominio, nomeadamente á gestão dos DNS records.
    2. Caso não exista ainda, adicionar um registo do tipo TXT. A titulo de exemplo podemos ter a seguinte entrada SPF: “v=spf1 ip4:192.168.0.1/24 -all”.
      1. v=spf1 – indica a versão do spf a implementar (actualmente é usada a versão 1).
      2. ip4: 192.192.168.0.1/24 – indica o endereço do servidor de email usado pelo dominio da Empresa1
      3. -all – Indica “fail” (falha). Email que naõ venham da rede estipulada pelo campo ipv4 não são autorizados.
  3. Configurar uma entrada DKIM no nosso dominio.
    1. Publicar a chave publica do nosso dominio no nosso regissto de DNS.
    2. O registo TXT de DKIM no nosso dominio será algo semelhante a: “v=DKIM1; p=MIGMHY7ssE3RTfgTghYu675432DDfrtewdrrRRENBVgh……”.
      1. v=DKIM1 – indica a versão de DKIM a usar (actualmente é usada a versão 1)
      2. p=MIGMHY7ssE3RTfgTghYu675432DDfrtewdrrRRENBVgh…… – indica a chave publica do nosso dominio.
  4. Configurar uma entrada DMARC no nosso dominio

 

 

 

Para mais informações sobre este ou outro qualquer tema contactar: [email protected]