Quais são os melhores métodos para capturar spam com raquetes de neve?

Question

Estou usando o Smartermail para meu pequeno servidor de e-mail. Temos tido um problema ultimamente de obter ondas de spam de snowshoe que seguem o mesmo padrão. Eles vêm em lotes de 3 ou 4 de cada vez. Os corpos são quase idênticos, exceto pelo nome de domínio ao qual eles se conectam. Os IPs de origem tendem a ser do mesmo bloco / 24 por algum tempo, depois mudam para outro / 24. Os domínios tendem a ser novos. Eles têm registros válidos de PTR e SPF e têm rabiscos aleatórios na parte inferior do corpo para falsificar os filtros bayesianos.

Estou usando uma dúzia de RBLs diferentes, incluindo Barracuda, Spamhaus, SURBL e URIBL. Eles fazem um trabalho decente pegando a maioria deles, mas ainda temos muito a escorregar porque os IPs e domínios não foram colocados na lista negra.

Existe alguma estratégia que eu possa empregar, incluindo RBLs que bloqueiam domínios recém-criados ou lidam especificamente com spam snoeshow? Eu estou esperando para evitar ter que usar um serviço de filtragem de terceiros.

    

Answer 1

Isso está se tornando um problema real para seus usuários?

Eu recomendaria um serviço de filtragem de e-mail completo neste momento. Bayesian não é mais tão quente assim. Reputação, RBL, cabeçalho / intenção-análise e outros fatores parecem ajudar mais. Considere um serviço de filtragem na nuvem para combinar várias abordagens ( e volume coletivo ) para fornecer melhor proteção ( eu uso a solução de nuvem ESS da Barracuda para minha clientes ).

E, é claro: Luta contra Spam - O que posso fazer como: administrador de e-mail, proprietário do domínio ou usuário?

Nós não fomos afetados negativamente pelo aumento nos ataques de Snowshoe. Eu vi um período em que o volume de e-mails triplicou no dia-a-dia com esses ataques. Mas nenhuma das coisas ruins passou por isso. Em 3 dias, Barracuda trouxe os volumes para níveis normais.

Acho que as soluções de filtragem que têm uma visão ampla da atividade de e-mail mundial podem reagir aos ataques melhor do que os filtros de e-mail individuais.

Editar:

Isso também foi discutido recentemente na lista de discussão LOPSA :

Minha contribuição: link
Outra opinião: link

    

Answer 2

Sou um funcionário do DNS Ops que trabalha de perto com um grupo que está frequentemente sujeito a esses ataques. Lidar com ataques de snowshoe é principalmente um problema de processo e, como a ewwhite aponta, pode estar fora do escopo de sua empresa resolver internamente. Eu diria que, a menos que você tenha uma operação considerável e vários feeds RBL comerciais, você provavelmente não deveria estar tentando resolver isso sozinho usando um serviço de filtragem comercial.

Dito isso, temos alguma experiência com isso e é mais interessante compartilhar do que não. Alguns pontos de contato são:

• Se possível, treinar sua plataforma de e-mail para identificar as características de um ataque com snowshoe em andamento e rejeitar temporariamente mensagens das redes em questão. Clientes bem comportados tentarão reenviar mensagens em uma falha temporária, outros não.
• Certificando-se de que seus administradores de DNS estão monitorando UDP-MIB::udpInErrors via SNMP, porque as plataformas de email são muito capazes de sobrecarregar as filas de recebimento de ouvintes UDP quando um ataque com raquetes de neve está em andamento. Se não estiverem, uma maneira rápida de saber no Linux é executar netstat -s | grep 'packet receive errors' nos servidores DNS em questão; uma contagem grande indica que eles precisam sair de seus duffs e começar a prestar atenção. Eles precisarão adicionar capacidade ou aumentar o tamanho dos buffers de recebimento se o derramamento freqüente estiver ocorrendo. (o que significa perda de consultas ao DNS e perda de oportunidades de prevenção de spam)
• Se você costuma ver esses ataques utilizando domínios recém-criados, existem RBLs que destacam esses domínios. Um exemplo de um é FarSight NOD (as pessoas que estiverem lendo isto devem realizar sua própria pesquisa), mas não é livre.

Divulgação total: A Farsight Security foi fundada por Paul Vixie, que tenho o péssimo hábito de desabafar quando as pessoas violam os padrões de DNS.

    

Answer 3

Instalei o Declude (que é gratuito) e o Message Sniffer (que não é) e nos últimos 4 dias vi uma mensagem de spam na minha conta de e-mail de teste, em oposição às dezenas que recebia por dia . Tanto quanto eu posso dizer, não tivemos bons emails filtrados. Spamassassin provavelmente também seria uma boa solução, embora eu não tenha tido sorte com isso quando experimentei o Spam Assassin em uma caixa ..

    

Answer 4

Muitas das respostas aqui são para o anti-spam em geral. Até certo ponto, isso faz sentido, já que os spammers parecem estar se encaminhando para o snowshoe como um método de entrega preferido.

O Snowshoe era originalmente enviado de datacenters em baixo volume (por IP) e sempre incluía um link de cancelamento de assinatura (para não dizer se funciona). Hoje em dia, o snowshoe quase nunca tem informações de cancelamento de assinatura e é enviado em alto volume a partir de seus IPs, mas é enviado em um burst para que, quando o IP for colocado na lista negra, já esteja enviando emails. Isso é chamado spam de granizo .

Por causa disso, as DNSBLs e até mesmo as assinaturas baseadas em padrões apertados são horríveis na captura de spam com snowshoe. Há algumas exceções, como a lista Spamhaus CSS (que é especificamente voltada para redes com raquetes de neve e faz parte do SBL e ZEN), mas em geral você precisará de greylisting / tarpitting (que pode atrasar a entrega até os DNSBLs alcançarem) e, mais importante, um sistema de aprendizado de máquina baseado em token como Filtragem de spam baiana . Bayes é particularmente bom em detectar snowshoe.

A resposta de Andrew B menciona os Domínios e Hostnames (NOD) recentemente adquiridos da Farsight Security, que tentam antecipar redes de snowshoe à medida que são transformados, mas antes de começarem a enviar spam. Spamhaus CSS provavelmente faz algo semelhante. O CSS está pronto para uso em um ambiente de bloqueio, enquanto o NOD é realmente projetado para ser um feed para um sistema personalizado em vez de um sistema autônomo / de bloqueio.