Estou usando o Smartermail para meu pequeno servidor de correio. Ultimamente, temos tido um problema ao receber ondas de spam de sapatos de neve que seguem o mesmo padrão. Eles vêm em lotes de 3 ou 4 por vez. Os corpos são quase idênticos, exceto pelo nome de domínio ao qual estão vinculados. Os IPs de origem tendem a ser do mesmo bloco / 24 por algum tempo, depois alternam 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 filtros bayesianos.
Estou usando uma dúzia de RBLs diferentes, incluindo Barracuda, Spamhaus, SURBL e URIBL. Eles fazem um trabalho decente capturando a maioria deles, mas ainda temos muita coisa a ver porque os IPs e domínios não foram incluídos na lista negra.
Existem estratégias que eu possa empregar, incluindo RBLs que bloqueiam domínios recém-criados ou lidam especificamente com spam de snoeshow? Espero evitar ter que usar um serviço de filtragem de terceiros.
Respostas:
Isso está se tornando um problema real para seus usuários?
Eu recomendaria um serviço completo de filtragem de e-mail neste momento. Bayesian não é mais tão quente assim. Reputação, RBL, análise de cabeçalho / intenção e outros fatores parecem ajudar mais. Considere um serviço de filtragem em nuvem para combinar várias abordagens ( e volume coletivo ) para fornecer melhor proteção ( eu uso a solução em nuvem ESS do Barracuda para meus clientes ).
E, é claro: Combate ao spam - O que posso fazer como administrador de email, proprietário de domínio ou usuário?
Não fomos afetados negativamente pelo aumento nos ataques com raquetes de neve. Vi um período em que o volume de mensagens triplicou no dia-a-dia com esses ataques. Mas nenhuma das coisas ruins conseguiu passar. Em 3 dias, o Barracuda reduziu os volumes aos níveis normais.
Eu acho que as soluções de filtragem que têm uma visão ampla da atividade de email em todo o mundo podem reagir melhor aos ataques do que os filtros de email individuais.
Editar:
Isso também foi discutido recentemente na lista de correspondência da LOPSA :
Minha contribuição: https://www.mail-archive.com/[email protected]/msg04180.html
Outra opinião: https://www.mail-archive.com/[email protected]/msg04181 .html
fonte
Sou um funcionário de operações de DNS que trabalha em estreita colaboração com um grupo que está frequentemente sujeito a esses ataques. Lidar com ataques com raquetes de neve é principalmente um problema de processo e, como a ewwhite aponta, pode estar além do escopo da sua empresa resolver internamente. Eu diria até que, a menos que você tenha uma operação considerável e vários feeds RBL comerciais, provavelmente não deveria tentar resolver isso sozinho usando um serviço de filtragem comercial.
Dito isto, temos alguma experiência com isso e é mais interessante compartilhar do que não. Alguns pontos de contato são:
UDP-MIB::udpInErrorsvia SNMP, porque as plataformas de correio são muito capazes de sobrecarregar as filas de recebimento de ouvintes UDP quando um ataque de neve está em andamento. Se não estiverem, uma maneira rápida de saber no Linux é executarnetstat -s | grep 'packet receive errors'nos servidores DNS em questão; uma grande contagem indica que eles precisam sair de suas duffs e começar a prestar atenção. Eles precisarão adicionar capacidade ou aumentar o tamanho dos buffers de recebimento se ocorrer derramamento frequente. (o que significa consultas de DNS perdidas e oportunidades perdidas de prevenção de spam)Divulgação completa: A Farsight Security foi fundada por Paul Vixie, que eu tenho o mau hábito de denunciar quando as pessoas violam os padrões de DNS.
fonte
Eu instalei Declude (que é gratuito) e Message Sniffer (que não é) e nos últimos 4 dias eu vi uma mensagem de spam entrar na minha conta de e-mail de teste, em oposição às dezenas que estava recebendo por dia. Pelo que sei, não tivemos um bom email filtrado. O Spamassassin provavelmente também seria uma boa solução, embora eu não tenha tido sorte quando tentei o Spam Assassin in a Box.
fonte
Muitas das respostas aqui são para anti-spam geral. Até certo ponto, isso faz sentido, pois os remetentes de spam parecem estar caminhando em direção à raquete de neve como o método de entrega preferido.
O Snowshoe era originalmente sempre enviado de datacenters em baixo volume (por IP) e sempre incluía um link de cancelamento de assinatura (para não dizer se funciona). Atualmente, o snowshoe quase nunca tem informações de cancelamento de assinatura e é enviado em alto volume de seus IPs, mas é enviado em uma explosão para que, quando o IP for colocado na lista negra, já terminei de enviar e-mails. Isso é chamado de spam de tempestade de granizo .
Por esse motivo , DNSBLs e até assinaturas rígidas baseadas em padrões são horríveis ao capturar spam de sapatos de neve. Existem algumas exceções, como a lista CSS do Spamhaus (que é especificamente direcionada às redes de raquetes de neve e faz parte do SBL e do ZEN), mas, em geral, você precisará de lista de cinza / tarpitting (que pode atrasar a entrega até que os DNSBLs atinjam) ) e, mais importante, um sistema de aprendizado de máquina orientado a tokens, como a filtragem de spam bayesiana . Bayes é particularmente bom em detectar raquetes de neve.
A resposta de Andrew B menciona os novos domínios e nomes de host (NOD) da Farsight Security , que tenta antecipar as redes de raquetes de neve à medida que elas são ativadas, mas antes de começarem a enviar spam. O Spamhaus CSS provavelmente faz algo semelhante. O CSS está pronto para uso em um ambiente de bloqueio, enquanto o NOD é realmente projetado para alimentar um sistema personalizado, em vez de um sistema autônomo / de bloqueio.
fonte