[MASOCH-L] Guerra aos IPs dinâmicos

[Paulo Henrique]

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.