[MASOCH-L] Guerra aos IPs dinâmicos

Thu Apr 20 08:09:11 BRT 2017

Saudações Leandro,

Torno a levantar o principal ponto, e em 20 anos, onde provavelmente
estaremos lidando com 20 a 30 bilhões de endereços, e não descarte os
demais recursos anti-spam. Qual será o custo computacional?

Att.

Em 19/04/2017 18:08, "Leandro" <leandro at spfbl.net> escreveu:
>
> Oi Paulo. Concordo 100% contigo. É mais fácil dizer o que é servidor de
> e-mail legítimo do que dizer o que não é.
>
> Apesar da gente não estar fazendo exatamente isso, estamos fazendo algo
> parecido. A ideia é classificar todos IPs que há certeza de não serem e
> nunca serão servidores de e-mail e bloquear tudo. Ai o que sobra, a gente
> bloqueia por demanda aquilo que houver forte suspeita de não puder ser.
> Sendo bloqueado indevidamente, o admin consegue tirar o IP da lista se
> houver servidor de e-mail legítimo lá. Se você estender esse processo a um
> longo período de tempo terá uma lista negativa que você sugeriu. Bem
> precisa.
>
> Sobre o custo computacional de processar tudo isso, não é tão grande assim
> se usar a estrutura de dados certa. A gente resolveu esse problema
> trabalhando com funções de join() e split() na notação CIDR. A busca de um
> IP na lista CIDR é log2(n) pois você normaliza o CIDR contendo todos os
> dígitos, sem omissão alguma, e busca o valor mais próximo anterior pelo IP
> normalizado, da mesma forma, e fecha com uma função contained() do IP
sobre
> o CIDR encontrado.
>
> Para você ver como é bem rápido e consome pouca memória, a latência de
> processamento das nossas consultas DNBSL está em 1ms (sem contar a
latência
> de rede, somente processamento interno) e a memória usada é menor que
> 100MB. Isso levando em conta todo universo de IPv4 mais IPv6.
>
> Leandro
> SPFBL.net
>
> Em 19 de abril de 2017 13:09, Paulo Henrique <paulo.rddck at bsd.com.br>
> escreveu:
>
> > Olá a todos,
> > A criação de um cadastro publico de MTA não seria mais produtivo ?
> > Penso que daqui a 20 anos quando houver entre 20 a 25 bilhões de
> > dispositivos conectados na rede, o custo computacional para manter uma
> > filtragem desse nivel será proibitivo ou no minimo realmente oneroso a
> > instituição.
> > As grandes MTAs já tem meio passo desse cadastro, no caso a propria
> > Microsoft já exige o cadastramento da MTA para que os e-mails sejam
> > entregues corretamente.
> > Uma base de validação de MTA nos mesmos moldes do DNSSec será muito mais
> > produtivo do que esse esforço de analise de reverso e tantas outras
> > soluções.
> >
> > Att.
> >
> >
> > Em 19 de abril de 2017 08:06, Leandro <leandro at spfbl.net> escreveu:
> >
> > > Em 18 de abril de 2017 15:09, Leandro <leandro at spfbl.net> escreveu:
> > >
> > > > Em 18 de abril de 2017 14:33, Danton Nunes <
danton.nunes at inexo.com.br>
> > > > escreveu:
> > > >
> > > >> On Tue, 18 Apr 2017, Leandro wrote:
> > > >>
> > > >> Danton. Refletindo melhor sobre o assunto, percebi que essa
técnica do
> > > >>> "rastro de pólvora" só afeta IPs com reverso. Portanto o método é
> > > seguro,
> > > >>> desde que eu consiga registrar com precisão os padrões de reverso
> > > >>> utilizados em residências, tanto para IPv4 ou IPv6. Eu acho
> > importante
> > > >>> atacar o problema no IPv6 também, pois vai que a cafeteira do
sujeito
> > > >>> acorda de mau humor e descarrega toda sua ira na porta 25. Não é
> > > verdade?
> > > >>> :-)
> > > >>>
> > > >>> Ai o problema vai ficar restrito aos IPs sem reverso mesmo.
> > Paciência!
> > > >>>
> > > >>
> > > >> eu não vejo por que cadastrar reversos em IPv6, a não ser para
> > endereços
> > > >> notáveis. por outro lado a ausência de reverso pode ser uma pista
de
> > > que se
> > > >> trata de usuário final e não um MTA, mas só uma pista, porque
também
> > > nada
> > > >> obriga a um MTA ter seu(s) endereço(s) com reverso bonitinho.
> > > >>
> > > >> então, acho que esse critério pode ser usado para atribuir pontos
em
> > vez
> > > >> de determinar um bloqueio definitivo.
> > > >>
> > > >> os endereços SLAAC são facilmente identificáveis porque carregam a
> > > >> assinatura 0xFFFE a partir do bit 80 até o 95 (contando os bits a
> > > partir de
> > > >> zero e da ponta mais significativa do endereço). Bloquear ou
atribuir
> > > uma
> > > >> nota de suspeita a um endereço SLAAC pode ser uma boa política.
> > > >> Dificilmente um servidor de verdade tem um endereço assim,
normalmente
> > > tem
> > > >> endereços estáticos. note que um teste como este não requer sequer
uma
> > > >> consulta de DNS e pode até ser implementado pelo firewall, se a
opção
> > > for
> > > >> pelo bloqueio, mascarando o campo do endereço. (p.ex. com
ip6tables no
> > > >> Linux)
> > > >>
> > > >> outro tipo de endereço que pode indicar que se trata de usuário
final
> > e
> > > >> não um servidor válido é o definido na RFC-4941. estes são mais
> > > difíceis de
> > > >> identificar, por não terem um padrão fixo como é o caso do SLAAC.
> > > >> entretanto, por conta mesmo da forma como são gerados, tem alta
> > > entropia,
> > > >> aproximadamente metade dos bits em zero, como não costuma ser o
caso
> > com
> > > >> endereços de servidores válidos. de qualquer forma melhor não usar
> > isto
> > > >> como critério de bloqueio, mas sim de pontuação. 64bits muito
> > > "aleatórios"
> > > >> no rabo do endereço IP, mais x pontos de suspeita de spam.
> > > >>
> > > >> a entropia de uma mensagem é H=-Soma(i)[Pi log2(Pi)], no nosso
caso i
> > > >> pode ser 1 ou 0. P0 = númerio de zeros / 64, P1 = número de uns /
64 =
> > > >> 1-P0, logo H = - ( P0 log2(P0) + (1-P0) log2(1-P0) ) Quando as
> > > quantidades
> > > >> de uns e zeros são iguais, H=1. Quando todos os bits são iguais
H=0.
> > > >>
> > > >
> > > > Cacete. Que aula!
> > > >
> > > > Vou implementar a verificação SLAAC, pois é fácil e rápido verificar
> > bits
> > > > do endereço IP.
> > > >
> > >
> > > Consegui implementar a verificação de SLAAC dentro do SPFBL:
> > >
> > > http://matrix.spfbl.net/dnsbl/2000:1234:5678::EBFF:FEA4:C1AE
> > >
> > > Programei ele para me avisar os casos que aparecem com esta flag para
eu
> > > bolar uns gatilhos de bloqueio depois.
> > >
> > > Vou esperar juntar uma boa amostragem para fazer isso sem medo. Quero
ver
> > > se aparece algum caso não previsto e saber também o quanto podemos ser
> > > agressivos com esse tipo de verificação.
> > >
> > >
> > > > Depois eu vou estudar com mais cuidado essa RFC-4941 para ver se
> > consigo
> > > > bolar algo útil.
> > > >
> > > > Valeu Danton!
> > > >
> > > >
> > > >>
> > > >> -- Danton
> > > >>
> > > >> __
> > > >> masoch-l list
> > > >> https://eng.registro.br/mailman/listinfo/masoch-l
> > > >>
> > > >
> > > >
> > > __
> > > masoch-l list
> > > https://eng.registro.br/mailman/listinfo/masoch-l
> > >
> >
> >
> >
> > --
> > :UNI><BSD:
> > Paulo Henrique.
> > Fone: (21) 37089388.
> > __
> > masoch-l list
> > https://eng.registro.br/mailman/listinfo/masoch-l
> >
> __
> masoch-l list
> https://eng.registro.br/mailman/listinfo/masoch-l