[MASOCH-L] Guerra aos IPs dinâmicos

Thu Apr 20 08:38:46 BRT 2017

Oi Paulo. Sei aonde você quer chegar. Você está imaginando usar a estrutura
de dados do BIND com esses bilhões de endereços:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/3/html/Reference_Guide/s1-bind-zone.html

Pode ter certeza que todas as tecnologias que usam essa estrutura irão
morrer nesse cenário que você mostrou, pois nenhum recurso computacional
será suficiente.

Eu acho que não caiu ainda a ficha da maioria dos profissionais da área de
combate ao SPAM sobre esse problema.

Imagine um hacker escrevendo um código para entrar num roteador e enviar
e-mail usando um endereço IPv6 para cada e-mail enviado:

   - Aloca 2001:DB8::1 e dispara o e-mail 1
   - Aloca 2001:DB8::2 e dispara o e-mail 2
   - Aloca 2001:DB8::3 e dispara o e-mail 2
   - ...
   - Aloca 2001:DB8::FFFF e dispara o e-mail 65535
   - ...

Eu não sou especialista em BIND, mas se alguém tentar resolver esse
problema com o DNSBL e BIND, terá sérios problemas pois o código malicioso
poderia alocar aproximadamente 2^64 endereços IP distintos para enviar 2^64
emails.

Não sei se é possível agrupar os endereços no BIND mas, ainda que seja
possível, haverá o problema de haver apenas um endereço válido no meio
destes 2^64 e se você tentar listar os 2^64-1 sem listar esse um especifico
terá uma base gigante.

Nosso projeto não trabalha com esse tipo de estrutura de dados. Quando esse
cenário virar realidade, estaremos trabalhando exatamente com os mesmos
recursos de hoje.

Leandro
SPFBL.net

Em 20 de abril de 2017 08:09, Paulo Henrique <paulo.rddck at bsd.com.br>
escreveu:

> 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
> __
> masoch-l list
> https://eng.registro.br/mailman/listinfo/masoch-l
>