[MASOCH-L] Guerra aos IPs dinâmicos

Thu Apr 20 09:28:42 BRT 2017

Leandro,

Creio que não expressei-me corretamente, vou tentar explicar.

Com o adivento do IPv6, o spammer deixa de ter a limitação atual do IPv4,
conseguir um /24 IPv4 para enviar spam é complicado, sendo este meio que um
fator por limitação tecnologica, o cara até tem recurso computacional para
enviar 1 trilhão de e-mails/mes mas com apenas 254 ips rapidamente o bloco
é taxado e a campanha é morta ali mesmo, como alternativa, eles hoje usam
botnets espalhadas em equipamentos de usuario final, nesse caso o projeto
discutido na thread é até positivo mas ainda requer um certo esforço humano
na determinação de como foi cadastrado o reverso para usuarios finais ou no
caso do IPv6 não foi, e sempre será uma briga de gato e rato entre o
sysadmin e o spammer, pois se o spammer mudar o reverso do bloco em poucas
horas os IPs podem até estar barrados mas a nova entrada de reverso não
estará, tornando a gastar mais recursos humanos, energia e banda de
comunicação.

Considerando a exigência do cadastro da MTA pelo sysadmin para que o e-mail
dessa MTA seja recebido nas demais MTAs "sérias", quem realmente precisa do
serviço de e-mail terá que se cadastrar manualmente as suas MTAs pois do
contrario não terá o serviço corretamente funcionando, o spammer pode até
fazer o cadastro e conseguir enviar alguns e-mails, mas logo as demais MTAs
irão detectar a pratica e darão damped na MTA e tudo mais que esteja
relacionada a aquela MTA ( IP/Dominio/SPF/DKIM ), de preferencia faz como é
os dominios hoje, cobra uma taxa anual de manutenção do cadastro, quando a
coisa pesa no bolso muitos investimentos tornam-se tiro nos pés.

O lance do cadastro é fazer o esforço humano de cadastro ser tão grande e
as sansões por quem desrreipeitar os criterios dela serem muito maiores que
ao invés de lucro o spammer passa a ter prejuizo pois o tempo de fazer o
cadastro de uma MTA será maior do que o tempo de ativar mais uma MTA para
enviar spams

Considere que nesse cadastro seja requerido rodar um agent em que pega o
numero de serie do processador/HD e estes façam parte tanto do cadastro
como também passam a oculpar um  campo do cabeçalho SMTP do e-mail.
Se o servidor for marcado como spammer e ele de fato for de um spammer, ele
terá que se livrar do servidor fisico, agora se não for é só bolar um meio
de reativação da MTA.

Quanto ao processamento, a preocupação é quanto a quatidade de energia
eletrica, banda de comunicação, que está sendo desperdiçada só para manter
mensagens indesejadas fora das mailbox de suas MTAs.

Espero que tenha conseguido explicar.

Att.

Em 20 de abril de 2017 08:38, Leandro <leandro at spfbl.net> escreveu:

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

-- 
:UNI><BSD:
Paulo Henrique.
Fone: (21) 37089388.