[MASOCH-L] Guerra aos IPs dinâmicos

Wed Apr 19 18:08:30 BRT 2017

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
>