[GTER] Mais um motivo pra nao usar DNSSEC

[Henrique de Moraes Holschuh]

On 09-11-2011 20:15, Rubens Kuhl wrote:
> 2011/11/9<nelson at pangeia.com.br>:
>> On 09-11-2011 17:10, nelson at pangeia.com.br wrote:
>>> On Wed, Nov 09, 2011 at 04:17:20PM -0200, Henrique de Moraes
>>> Holschuh wrote:
>>>> On 09-11-2011 13:34, nelson at pangeia.com.br wrote:
>>>>> DNSSec e PKI pra resolver fraude bancaria?
>>>>
>>>> Não.  Para tornar mais difícil as fraudes em massa (DNSSEC), e
>>>> no caso
>>>
>>> Porque? Basta invadir ou disparar  email na maquina com dnssec.
>>
>> E isso é mais fácil e barato que envenenar cache de DNS?  Não que
>> eu saiba.
>
> Mais fácil não é, mas na minha contagem não científica (e portanto
> uma percepção pessoal) de episódios envolvendo DNS, o
> comprometimento de máquinas de DNS recursivo no país é mais
> recorrente do que os de poisoning. Notar que poisoning hoje é
> possível mas bem menos trivial

Realmente... e eu não duvido que você esteja correto na sua contagem
não-científica.

Considerando este cenário, para o DNSSEC proteger alguém de recursivo
comprometido, só com a validação end-to-end (ou seja, o host está
validando o DNSSEC).

A validação end-to-end tem pelo menos dois problemas:

1. Por enquanto, precisa instalar um resolver DNSSEC local nos unix-like
e no Windows.  No caso do Windows, suponho que isso tome a forma de
módulo de proteção do banco, ou de componente das "internet firewalls"
das companhias anti-vírus até a Microsoft resolver atualizar o sistema.

2. O host precisa exigir que a assinatura esteja presente, mesmo que sua
visão do DNS via recursivo (que foi comprometido) pareça indicar que a
assinatura não existe.

Acho que ainda estamos meio longe de chegar lá.  Em algumas hierarquias,
o ponto (2) acima é realizável (b.br, jus.br...), e já que você vai ter
que tomar alguma ação específica para garantir (1), pode configurar o
(2) também.

Ainda não ajuda em nada se o end-host ou o DNS autoritativo estiver
comprometido.

Mas torna bem aparente porque a obrigatoriedade do uso de hierarquias
onde DNSSEC não é opcional é um passo importante na direção da solução
(ou isso, ou o DNS tem que passar a ser irrelevante para a segurança
total do sistema, algo que parece estar ainda mais distante).

> agora que a grande maioria dos recursivos implementa
> anti-Kaminsky...

Eu sinceramente tenho minhas dúvidas se a grande maioria dos usuários
está atrás de recursivos que foram atualizados para implementar
anti-Kaminsky.  Testar isso não é muito fácil, você precisa ter acesso
ao serviço recursivo do servidor a ser testado, e ainda por cima muita
rede andou bloqueado o teste via DNS-OARC[1].

Desconfio que muito recursivo embarcado em roteador doméstico e algumas
soluções verticalizadas até hoje não foram atualizados para defesa
contra o ataque de Kaminsky.  Ainda bem que (até onde sei), os
embarcados em geral não fazem muito caching e o grande problema com eles
é alteração da configuração para apontar para um recursivo pirata.

[1] Um utilitário simples para verificar isso "do lado de dentro" que
possa ser trivialmente executado por um usuário doméstico seria útil.

-- 
Henrique de Moraes Holschuh <hmh at ima.sp.gov.br>
IM@ - Informática de Municípios Associados
Engenharia de Telecomunicações
TEL +55-19-3755-6555/CEL +55-19-9293-9464

Antes de imprimir, lembre-se de seu compromisso com o Meio Ambiente
e do custo que você pode evitar.