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. Using DNS blocklists at the initial email connection

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:

  • Lista de bloqueio da Spamhaus (SBL)
  • Lista de bloqueio de explorações (XBL)
  • Lista de bloqueio de polí­tica (PBL)

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, como por exemplo: (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 direta de DNS em relação ao SBL.

Consulte o domí­nio MAIL FROM (caminho de retorno)

Depois da HELO, durante a conexão SMTP, vem o comando MAIL FROM.  Ele costuma ser chamado de “Envelope de” ou “Caminho de retorno”. Você deve consultar o domí­nio incluí­do nessa string, como por exemplo: <[email protected]>

Sempre que uma consulta é feita no DBL e no 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 do e-mail quanto do conteúdo. 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!

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.  

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 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 “amigável de”, ele deve ser consultado em relação ao HBL, e o domí­nio contido nele deve ser consultado em relação ao DBL e 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 cara 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 direta de DNS 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 de SMTP pré-dados e análise de conteúdo.

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.

Spamhaus Botnet Threat Update, Q2 2021

13 July 2021

Report

Researchers may have observed a 12%reduction in botnet command and controllers (C&Cs), however, more than one industry-leading provider is struggling to keep on top of botnet activity.