As listas de bloqueio do sistema de nome de domínio (DNSBLs) são uma forma econômica e eficaz de interromper a torrente de tráfego de e-mails recebidos associada a spams e outros e-mails maliciosos.  O uso de listas de bloqueio traz vários benefícios, reduzindo custos de infraestrutura e horas de mão de obra para aumentar as taxas de captura.  No entanto, para tirar o máximo de proveito dos DNSBLs, é crucial usá-los nos pontos certos em seu processo de filtragem de e-mail.

Filtragem eficiente e eficaz

Há uma ampla gama de opções de segurança de e-mail para sua infraestrutura, desde varredura e filtragem de conteúdo até ferramentas baseadas em rede que usam métodos distribuídos e colaborativos.

Infelizmente, a maioria dos itens acima é cara e demanda muitos recursos.  A chave para a filtragem de e-mail é remover a maior parte dos e-mails indesejados logo no início do processo, antes que cheguem à fase de inspeção de conteúdo, que demanda muitos recursos.

Uma verificação DNSBL é o método mais simples, rápido e econômico que você tem à sua disposição… então por que não usá-lo?

 

Fases para utilizar DNSBLs

Ao aceitar e processar um e-mail, você deve usar listas de bloqueio em três áreas:

  1. Na conexão inicial — com base no IP de conexão.
  2. Ao longo da fase pré-dados de um e-mail, ou seja, a transação SMTP
  3. Assim que os dados do e-mail forem aceitos, ou seja, durante a inspeção de conteúdo

Benefícios de usar DNSBLs antes da filtragem de conteúdo

  • Economiza largura de banda — você reduz significativamente o número de mensagens que requerem download.
  • Economiza conexões abertas — muitas conexões não são mantidas abertas sem necessidade.
  • Economiza atividade de armazenamento — a rejeição antes da filtragem de conteúdo não usa nenhum recurso de armazenamento (com exceção de algumas linhas de registro).
  • Redução geral nos requisitos de memória, armazenamento e CPU — você tem um volume muito menor de e-mails que exigem uma varredura de conteúdo dispendiosa.

 

1. Uso de listas de bloqueio de DNS na conexão de e-mail inicial

No início de uma transação de e-mail, um servidor remoto tenta iniciar uma conexão com seu servidor.  Nesse ponto, uma rápida pesquisa (consulta) em uma lista de bloqueio pode instantaneamente (bem, quase instantaneamente) informar se o endereço IP de conexão está ou não associado a um comportamento malicioso.

Se o endereço IP estiver listado, você pode optar por cancelar a conexão de imediato.  Lembre-se de que essa consulta é realizada antes mesmo de ocorrer o handshake de SMTP (Simple Mail Transfer Protocol).

Quais listas de bloqueio usar:

  • Spamhaus Blocklist (SBL)
  • Lista de bloqueio de exploits (XBL)
  • Lista de bloqueio de política (PBL)

2. Uso de listas de bloqueio de DNS durante a fase pré-dados

O que é a fase pré-dados?

Todos os comandos de e-mail que ocorrem após a configuração da conexão de e-mail inicial (conforme detalhado acima) e antes do comando DATA durante a conexão SMTP são chamados de fase pré-dados.

Verifique o DNS reverso (rDNS) do IP de conexão

Assim que a conexão for aberta, você (o destinatário) deve fazer uma pesquisa de DNS reverso do endereço IP de conexão.

O resultado da verificação de rDNS corresponde à string HELO?

O resultado da pesquisa acima deve ser consultado com base no domínio contido na HELO do remetente, p.ex.: (HELO mta-out.someisp.example). Se não houver correspondência, a conexão deve ser interrompida imediatamente.  Isso é uma indicação de que o remetente não é quem diz ser (por exemplo, spoofing).  

Consulte o resultado do rDNS em relação às listas de bloqueio

O domínio resultante deve ser consultado em relação ao DBL e ao ZRD.

Consulte o domínio contido na HELO em relação às listas de bloqueio

O domínio contido na HELO deve ser consultado em relação ao DBL e ao ZRD, juntamente com a execução de uma pesquisa de DNS direto em relação ao SBL.

Consulte o domínio MAIL FROM (Return-path)

Depois da HELO, durante a conexão SMTP, vem o comando MAIL FROM.  Ele costuma ser chamado de “Envelope-from” ou “Return-path”. Você deve consultar o domínio incluído nessa string, p.ex.: <[email protected]>

Sempre que uma consulta é feita em relação ao DBL e ao ZRD, e o resultado é uma resposta positiva, os destinatários podem rejeitar o e-mail ou marcá-lo para uma inspeção posterior durante o processo de filtragem de conteúdo.

A transferência do cabeçalho e do conteúdo do e-mail 

Quando o comando RCPT TO é concluído, o comando DATA segue, e é ele que inicia a transferência de dados, tanto do cabeçalho quanto do conteúdo do e-mail. Depois que o destinatário confirma a execução bem-sucedida, o remetente transmite um comando QUIT, antes ou depois da inspeção do conteúdo, e a conexão é fechada.

A conexão fica aberta durante a inspeção de conteúdo?

Isso vai depender de suas decisões de implementação e escolhas de software.  Tal como acontece com todas as opções, existem prós e contras nos dois casos:

Algumas implementações optam por manter a conexão aberta até que tenham o resultado da inspeção do conteúdo.

Prós: os remetentes sempre serão notificados de uma rejeição, que é a melhor estratégia caso ocorram falso positivos.

Contras: isso demanda muitos recursos e seu MTA deve estar à altura da tarefa, mesmo durante picos. Recursos insuficientes podem gerar atrasos.

A maioria das implementações fecha a conexão antes da inspeção de conteúdo.

Prós: reduz os custos por exigir menos recursos.

Contras: em caso de falso positivos, o remetente não será notificado.

 

Uma análise mais detalhada dos benefícios de usar DNSBLs antes da filtragem de conteúdo

Redução da carga colocada em seus recursos

Como mencionado anteriormente, a varredura e a filtragem de conteúdo exigem muitos recursos. Reduzir o número de e-mails que chegam a esse ponto do processo de filtragem de e-mail economiza memória, reduz a potência de processamento e reduz a latência.

Proteção da infraestrutura contra campanhas de spam

Imagine uma situação em que você recebe centenas de mensagens por segundo durante uma campanha contínua ou crescente de spam.  Caso dependa da varredura ou da filtragem de conteúdo para mitigar o ataque, sua infraestrutura de e-mail pode entrar em colapso com a carga imposta pela imensa quantidade de e-mails recebidos.

Se tiver sorte e isso não acontecer, você ainda terá custos elevados, pois cada e-mail precisa ser baixado e analisado.

Os remetentes podem depurar problemas de retransmissão de e-mail

Quando um e-mail é rejeitado na conexão inicial ou no handshake de SMTP, o resultado é uma notificação de status de entrega (DSN) em tempo real ao remetente, avisando-o da falha na entrega.  Da perspectiva do remetente, isso pode ajudar a identificar e resolver problemas de retransmissão de e-mail.

Os e-mails não ficam em pastas de lixo eletrônico

Com a rejeição de e-mails no início da transação de e-mail, possíveis e-mails de spam não são baixados e esquecidos em uma pasta de lixo eletrônico.  Isso impede que os usuários finais vasculhem a pasta de lixo eletrônico em busca de um e-mail legítimo entre centenas, senão milhares de spams.

Infraestruturas de terceiros inocentes não são inundadas com mensagens de retorno

Se o endereço do remetente for forjado, o terceiro inocente cujo e-mail foi usado no endereço forjado do remetente receberá uma enxurrada de mensagens de retorno.

Maior proteção contra campanhas de spam com hailstorm e snowshoe

O uso de listas de bloqueio de domínio, bem como listas de bloqueio de IP, fornece proteção extra contra spams com hailstorm e snowshoe, além de outras ameaças. Para uma compreensão mais aprofundada desse assunto, sugerimos a leitura do artigo MTA developers: allow use of domain DNSBLs at the SMTP level.

É importante lembrar que nossa lista de bloqueio de domínio conterá muitos domínios antes que eles se tornem públicos!

 

3. Uso de listas de bloqueio de DNS durante a fase pós-dados

Depois que o comando DATA é executado e o cabeçalho e o conteúdo do e-mail são transmitidos ao destinatário, a inspeção do conteúdo começa, juntamente com a execução das verificações SPF, DKIM e DMARC.

Os cabeçalhos de e-mail contêm dados estruturados e podem ser analisados com bem menos recursos se comparados ao corpo de um e-mail. Para compreender melhor o cabeçalho e os componentes do corpo de um e-mail, leia ++Understanding the source code of a malicious email Understanding the source code of a malicious email.

Veja onde as listas de bloqueio podem ser usadas durante a inspeção de cabeçalho:

Consulte o endereço IP de origem:

Esse é o endereço IP contido na cadeia de recebimento da transação original, ou seja, o que deu origem ao e-mail.  Essa pesquisa pode ser feita em relação ao SBL e ao AUTH BL. Uma pesquisa de rDNS também pode ser feita em relação ao DBL e ao ZRD.

Consulte o endereço para resposta:

O endereço de e-mail completo nesse campo deve ser consultado na lista de bloqueio de hash (HBL), que contém hashes criptográficos de endereços de e-mail.

Consulte o endereço do remetente:

Comumente conhecido como o endereço “Friendly From”, ele deve ser consultado em relação ao HBL, e o domínio contido nele deve ser consultado em relação ao DBL e ao ZRD, com uma pesquisa direta de DNS em relação ao SBL.

Por fim, chegamos à inspeção do conteúdo (role para cima para refletir sobre todas as oportunidades que você teve de rejeitar o e-mail antes que ele chegasse a essa parte mais dispendiosa do processo de filtragem de e-mail!)

Domínios incluídos no corpo do e-mail

Todos os URLs de sites ou e-mails citados no conteúdo do corpo do e-mail devem ser consultados em relação ao DBL, ZRD, com uma pesquisa de DNS direto em relação ao SBL.  Os e-mails contidos no corpo do e-mail também podem ser consultados em relação ao HBL.

Endereços de bitcoin incluídos no corpo do e-mail

Consulte-os em relação ao HBL, que tem uma seção de carteira de criptomoeda contendo hashes de bitcoin e outros endereços de criptomoeda.

Anexos de e-mail

Todos os anexos devem ser consultados em relação ao HBL, que lista arquivos de malware, além de endereços de e-mail e endereços de criptomoeda.

Como implementar tudo isso?

Infelizmente, com tantas variações, não é possível cobrir todos os detalhes operacionais específicos para diferentes sistemas de e-mail.  Quando algumas de nossas verificações não puderem ser implementadas, recomendamos entrar em contato com o suporte do produto que você está usando.

A boa notícia é que temos dois plugins para filtros de código aberto, SpamAssassin e Rspamd, para filtragem pré-dados (SMTP) e análise de conteúdo.  Veja também um diagrama de quais listas de bloqueio aplicar e onde aplicá-las.

Caso queira testar as listas de bloqueio de DNS e executar seu próprio servidor de e-mail, ++cadastre-se para acessar os dados gratuitamente por 30 dias++. E não deixe de compartilhar sua experiência conosco.

Produtos relacionados

Data Query Service (DQS)

O Data Query Service (DQS) da Spamhaus é uma solução acessível e eficaz para proteger seus usuários e sua infraestrutura de e-mail.

Usando sua solução já existente de proteção de e-mail, você será capaz de bloquear spams e outras ameaças relacionadas, incluindo malwares, ransomwares e e-mails de phishing.

O serviço nunca falhou e trabalha com as listas DNSBL mais utilizadas no setor.

  • Proativo e preventivo
  • Economia nos custos de gerenciamento e infraestrutura de e-mail
  • Acionável

Recursos

Dicas Top 10 (+1) para ter o seu próprio servidor de e-mail

Blog

Eis aqui 11 formas de ajudar no êxito dos administradores de e-mail que executam suas próprias infraestruturas de e-mail.

Seis vantagens de ter o seu próprio servidor de e-mail

Blog

Ter o seu próprio servidor de e-mail não é para qualquer um. Porém, um servidor de e-mail in loco tem suas vantagens.

Entendendo o código-fonte de um e-mail malicioso

Blog

Entenda as particularidades relacionadas a códigos-fonte de e-mail, assim você pode aplicar a inteligência de ameaças de IP e domínio no lugar certo do seu processo de filtragem de e-mail.