Estamos procurando uma maneira de bloquear spam com base na localização geográfica, filtrando usando o geoip.
contexto: raramente temos correspondência de e-mail fora dos EUA, portanto, gostaríamos de bloquear todos os e-mails recebidos fora dos EUA, exceto talvez um ou dois países.
Depois de pesquisar um pouco, encontrei algumas soluções que podem funcionar (ou não), mas gostaria de saber o que outros administradores estão fazendo atualmente ou o que recomendariam como solução.
Aqui está o que eu encontrei até agora:
Usando o PowerDNS e seu back-end GeoIP, é possível usar o geoip para filtragem. Normalmente este backend é usado para ajudar a distribuir a carga como um tipo de balanceamento de carga, mas eu não vejo por que ele não poderia ser usado para matar spam também?
Possivelmente use o banco de dados do país Maxmind e alguns scripts para fazer um trabalho semelhante.
O ideal é o que eu estou procurando é uma solução que lida com carga decente e escala bem também ... não somos todos! ;)
Agradecemos antecipadamente por sua ajuda! : -)
Existe também o patch do geoip para o netfilter / iptables para Linux. Você poderia usar isso para bloquear 25 para o seu servidor de e-mail, se for o Linux. Você poderia usar o Linux como um firewall para o seu servidor de email com este patch do iptables. A melhor parte é que é grátis: -)
A partir deste artigo de pesquisa sobre o SNARE , apresento este artigo:
For ham, 90% of the messages travel about 4,000 km or less. On the other hand, for spam, only 28% of messages stay within this range.
Minhas observações pessoais refletem a sua e observe que, mesmo agora em 2014, a localização geográfica continua sendo um excelente preditor de spam. Como outros apontaram, a localização do GeoIP (país ou distância) sozinho não é uma base suficientemente confiável para o bloqueio de conexões. No entanto, a combinação da distância do GeoIP com alguns outros dados sobre a conexão, como FCrDNS, validade do host HELO, sistema operacional remetente (via p0f) e SPF fornece uma base confiável de 99,99% (como em, 0,01% de chance de um FP) para rejeitar 80% das conexões antes da fase DATA.
Ao contrário de alguns testes SMTP (como uma listagem DNSBL em zen.spamhaus.org) que têm taxas muito baixas de FP, nenhum dos testes mencionados acima é uma base suficiente para rejeitar conexões. Aqui está outro padrão que se encaixa nessa categoria: o remetente do envelope usuário corresponde ao usuário do destinatário do envelope. Eu notei que cerca de 30% do spam segue esse padrão: [email protected] para: [email protected]. Acontece longe com mais frequência em spam do que em fluxos de e-mail válidos. Outro padrão de spammer é um envelope e um cabeçalho não correspondentes do domínio.
Ao classificar heuristicamente essas características de "spam", a base para um sistema de filtragem extremamente confiável pode ser montada. SpamAssassin já faz (ou pode fazer) a maior parte do que eu descrevi. Mas você também pediu uma solução que pudesse lidar com uma carga suficiente e dimensionar bem. Embora o SpamAssassin seja ótimo, não vi "consumo de recursos massivamente reduzido" em nenhuma parte das notas de versão 3.4.
Todos os testes listados no primeiro parágrafo ocorrem antes de SMTP DATA. Combinar esses primeiros testes forma uma base suficiente para rejeitar conexões com spam antes de DATA SMTP sem quaisquer falsos positivos. Rejeitar a conexão antes dos dados SMTP evita os custos de transferência de mensagens, bem como a carga mais pesada de CPU e rede de filtros baseados em conteúdo (SpamAssassin, dspam, validação de cabeçalho, DKIM, URIBL, antivírus, DMARC, etc.) para a grande maioria de conexões. Fazer muito menos trabalho por conexão é muito melhor.
Para o subconjunto menor de mensagens que são indeterminadas em SMTP DATA, a conexão pode continuar e eu classifico a mensagem com resultados dos filtros de conteúdo.
Para realizar tudo o que descrevi, fiz um pouco de hacking em um servidor SMTP baseado em node.js chamado Haraka. Ele escala muito, muito bem. Eu escrevi um plugin personalizado chamado Karma que faz a heurística de pontuação, e eu coloquei todas as pontuações de ponderação em um arquivo de configuração. Para ter uma idéia de como o karma funciona, dê uma olhada no arquivo de configuração karma.ini . Tenho recebido resultados de filtragem "melhores que o gmail".
Veja os testes executados pelo FCrDNS, helo.checks e data.headers também. Eles podem fornecer ideias adicionais de filtragem. Se você tiver mais ideias para detectar com segurança spam com testes baratos (pré-DATA), estou interessado em ouvi-los.
Outras perguntas que você precisa fazer: qual é a sua taxa aceitável de falso positivo e falso negativo (quanto de legitimidade você está disposto a perder e quanto de lixo você está disposto a aceitar?)
Qual latência adicional você está disposto a aceitar? Algumas técnicas anti-spam muito eficazes e pouco faladoras (por exemplo, greylisting) podem atrasar o correio. Isso pode irritar alguns usuários que (sem realismo) esperam que o email seja uma comunicação imediata.
Reflita sobre o quanto você deseja externalizar seus custos ao planejar um sistema anti-spam. Por exemplo, as listas negras baseadas no ipfilter são implacáveis, mas não afetam materialmente nenhum outro sistema. A lista cinza preserva a largura de banda do remetente e do destinatário, mas mantém as mensagens em filas remotas por mais tempo. Mensagens de rejeição de email e sistemas de desafio / resposta podem ser (ab) usados para enviar um email a um terceiro não relacionado. Técnicas como tarpitting ativamente externalizam custos, mantendo intencionalmente conexões SMTP abertas por longos períodos de tempo. As DNSBLs exigem que você ceda uma certa quantidade de controle a terceiros (mantenedores de listas negras), mas, em última análise, como administrador de e-mail, você é responsável por explicar sua política de bloqueio a seus usuários & gestão. O resultado é que existem considerações éticas que acompanham cada tecnologia e é importante estar ciente de seu efeito sobre os outros.
Quão tolerante você será em relação aos sistemas externos mal configurados? ( por exemplo, aqueles sem FCrDNS, sequências HELO / EHLO quebradas, pipelining não autorizado, aqueles que não tentam novamente corretamente após um código de falha temporário 4xx, etc. )
Quanto tempo, dinheiro, largura de banda e hardware você deseja dedicar ao problema?
Nenhuma técnica é eficaz, mas uma abordagem de defesa em profundidade pode reduzir substancialmente o lixo recebido. DNSBLs, URIBLs, greylisting, filtragem de conteúdo e white-lists e blacklists ajustadas manualmente funcionam bem em meu pequeno domínio, mas posso me dar ao luxo de ser mais liberal naquilo que rejeito.
A menos que as coisas tenham mudado recentemente, a IP de lista negra por país de origem não é muito eficaz. Eu tive a idéia de usar impressão digital ASN e OS (via p0f) para julgar a qualidade de uma conexão de entrada, mas não segui-lo; as estatísticas seriam interessantes de se olhar, mas não estou convencido de que seria mais útil do que as técnicas padrão já descritas. A vantagem de usar as informações de impressão digital do GeoIP, ASN e OS é que, embora possam ser indicadores de qualidade de conexão, eles estão disponíveis no tempo de conexão TCP / IP, muito antes de você atingir a camada SMTP (fsvo "long"). combinação, eles podem provar ser úteis e isso seria útil porque o spam fica mais caro para bloquear quando se aproxima do usuário final.
Eu não estou tentando ser um pessimista; As codificações de caracteres 'excêntricos' e as informações do GeoIP provavelmente se correlacionam bem com o spam, mas podem não ser confiáveis o suficiente para serem usadas como critérios únicos para bloquear o correio. No entanto, eles podem ser indicadores úteis em um sistema como o Spamassassin. A conclusão é que a defesa contra spam é um problema complexo na análise custo-benefício-risco e é importante saber quais são seus valores antes de implementar ou alterar um sistema.
Você não estaria simplesmente melhor usando algo como a lista de bloqueio do Spamhaus ZEN ( link )? É grátis se o tráfego de e-mail da sua organização tiver menos de 100.000 conexões SMTP e 300.000 consultas DNSBL por dia.
Concedidos, seus requisitos de uso ( link ) podem exigir uma inscrição no feed de dados se você fizer muito mais tráfego de e-mail diário, mas nesse nível de uso (leia as letras miúdas na parte inferior da página), você provavelmente não quer o ônus administrativo de gerenciar sua própria lista de bloqueios de qualquer maneira.
Usar uma combinação de DNSBL no servidor de email / nível de aplicativo e GEOIP no nível do servidor deve remover a maioria de seu spam sem ter que implementar pontuação de spam, pontos positivos, etc.
Isso é especialmente verdadeiro se seu servidor / empresa de e-mail receber apenas e-mails de vários países conhecidos, como EUA e Canadá.
O servidor de e-mail da Argosoft para Windows faz um bom trabalho, mas eu não estou ciente de uma solução similar baseada em Linux. É por isso que recomendo usar um MTA confiável no Linux (de preferência com DNSBL) e depois fazer uma solução GEOIP no nível do servidor.
Espero que isso ajude.
Pensei que você gostaria de saber que já existem fornecedores comerciais de anti-spam que fazem isso. Embora o IME seja adicionado a uma "pontuação" de spam para países fora de seu território, para evitar o bloqueio excessivo.
Pode ser bem integrado com o SpamAssassin, por exemplo?
Você também pode considerar em quais caracteres o e-mail está.
Quanto à implementação - existem alguns bancos de dados geo-IP acessíveis e comercialmente acessíveis. Eu estaria inclinado a integrar estes "manualmente" - assim você pode pelo menos deixar a mensagem chegar ao ponto em que você conhece o par destinatário do remetente, para o registro.
HTH
Tom
Eu tenho usado Sendmail junto com milter-greylist exatamente para esse propósito por vários anos em vários servidores de email de médio volume sem nenhum problema. É fácil configurar as regras desejadas do GeoIP, SPF, whitelist, DNSBL etc. em greylist.conf para aplicar seletivamente a lista cinza.
Aqui está um appliance em linha que funciona com roteadores e amp; firewalls para bloquear o tráfego IP por país e listas negras de IP em velocidades de linha. E o Arclight está correto, a menos que você esteja disposto a assumir um aumento de latência e cair em conexões TCP, você precisa de um dispositivo especializado como este IP Blocker da TechGuard para manter a proteção de velocidade de linha. O TechGuard também acaba de divulgar dados sobre o impacto de ACLs em roteadores e firewalls.
Tags networking email ip spam spam-filter