[MASOCH-L] Guerra aos IPs dinâmicos

Leandro leandro at spfbl.net
Wed Apr 19 08:06:27 BRT 2017


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
>>
>
>


More information about the masoch-l mailing list