[MASOCH-L] Guerra aos IPs dinâmicos

Leandro leandro at spfbl.net
Thu Apr 20 09:48:31 BRT 2017


Acho que entendi sim o seu cenário ideal Paulo. Mas creio que esse tipo de
abordagem, do cadastro de servidores, deva ser um trabalho tão oneroso que
simplesmente você bloquear tudo que existe, e ir liberando com a demanda,
seja mais fácil. Se a solução do seu problema depender a atitude de outras
pessoas, então eu creio que você estará numa grande fria.

Para fazer algo deste tipo, você teria que ter apoio de todos. Teria que
começar tentando convencer os donos destes servidores aqui a fazer esses
cadastros de MTA, deles próprios e de seus clientes:

http://blog.corujadeti.com.br/quem-possui-mais-servidores-no-mundo/

Uma coisa que pode facilitar muito para solução deste problema, seria
simplesmente pararmos de olhar para o IP e passarmos a olhar somente para o
domínio de remetente. Isso por si só já traria uma barreira considerável
aos spammers. Mas para chegarmos nesse ponto, de não precisarmos mais olhar
para o IP, o SPF teria que ser amplamente utilizado com -all. Essa
abordagem pelo remetente seria o ideal, pois não importa por qual IP o
e-mail está saindo. O IP se tornaria irrelevante neste caso. Ai podem
mandar até um IPv7 com 256 bits que nada mudaria.

Infelizmente usar -all é uma solução que também depende dos outros e, da
mesma forma que fazer o cadastro de MTA, estaríamos numa fria se
dependêssemos disso. :-)

Leandro
SPFBL.net

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

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


More information about the masoch-l mailing list