[MASOCH-L] Guerra aos IPs dinâmicos

[Danton Nunes]

On Thu, 20 Apr 2017, Leandro wrote:

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

há limites práticos no número de endereços IP que uma interface pode ter, 
no Linux isso é controlado pelo sysctl. a estratégia correta é alocar um 
endereço, enviar a porcaria, desalocar o endereço, voltar ao começo.

em algum momento vamos ter de desvincular totalmente o combate ao spam ao 
DNS, exceto talvez em protocolos como o SPF e listas negras. Minhas 
sugestões:

1. esqueçam o reverso. não faz parte da cultura IPv6 configurar reverso 
para todos os endereços. artifícios bonitinhos como geração automática de 
AAAA e PTR representam mera adição de burocracia.

2. flagar endereços SLAAC é trivial por causa da marca FFFE. admitir que 
endereços SLAAC são muito provavelmente de usuários finais é bastante 
razoável. o bom é que um teste destes custa zero.

3. Outros endereços dinâmicos não são tão facilmente identificáveis, mas 
devido à natureza aleatória dos 64 últimos bits podemos apelar para a 
hipótese de que servidores reais, configurados com endereços estáticos, 
tem baixa entropia nesses bits (isto é, muito mais 0s que 1s ou vice 
versa) enquanto dinâmicos tenderiam a ter alta entropia (uma distribuição 
mais uniforme de 0s e 1s.) Endereços com aproximadamente o mesmo número de 
0s e 1s poderiam ser flagrados como suspeitos de serem usuários finais.
Este teste também é de ordem zero e não demanda consulta de DNS.

4. procurar critérios que não dependam do IP, e estejam embutidos dentro 
do próprio protocolo de aplicação ou no transporte. uma ideia que me 
parece simples é verificar a validade do certificado usado para 
estabelecer a sessão TLS, quando for o caso, tanto para a MTA que recebe 
quanto para a que envia! Claro que o spammer pode arranjar um certificado 
válido, mas aí a CA que o assinou corre o risco de ser declarada 
não-confiável ou o próprio administrador do lado receptor pode manter uma 
lista revogação particular.

-- Danton (há mais de duas décadas na luta contra o spam)