Erros de certificado em “redirecionamento” no DNS RPZ de https / ssl

Question

Eu configurei um RPZ de DNS onde eu "redirecionava" os usuários para um jardim murado usando registros DNS RPZ quando os usuários tentavam acessar uma lista de sites ruins.

Digamos que um usuário tente acessar badsite.com. O redirecionamento para o meu jardim murado para conexões http funciona, mas para conexões https ele causa erros de certificado porque o URL no navegador permanece o mesmo (badsite.com), mas o IP resolvido está se conectando ao meu jardim murado (walledgarden.example.com).

Existe alguma maneira de resolver os erros de certificado ao usar o DNS RPZ para redirecionamento em conexões https?

    

Answer 1

Por um momento, quero que você finja que é um autor de malware que comprometeu com êxito os servidores DNS de sua empresa. Você está tentando usar o DNS para atender endereços IP falsos sempre que alguém tenta visitar um banco. Infelizmente, você não pode fazer com que esses avisos confusos do navegador desapareçam quando HTTPS for chamado.

Isso é basicamente o que você está nos pedindo para ajudá-lo. Suas intenções são benignas em comparação com esse suposto autor de malware, mas isso não muda o fato de que a tecnologia está funcionando como pretendido aqui. Você não pode projetar a segurança em torno da intenção.

Como a ação da diretiva ocorre no nível do DNS, não há como saber se o usuário está usando HTTP ou HTTPS no momento em que a consulta é enviada. A única coisa que você pode controlar é se vai ou não retornar um endereço IP e qual é o endereço IP.

Uma vez que você chegou nesse ponto, esse é um cenário básico de invasão de HTTPS. Todas as mesmas regras se aplicam. Se você estiver em posição de manipular as CAs confiáveis, poderá manipular os navegadores. Fora isso, sem dados.

Você tem quatro opções aqui:

1. Siga a sugestão do sebix nos comentários: envie um certificado da CA para todas as estações de trabalho que estarão sujeitas a essa proteção RPZ. Se isso é uma empresa, é perfeitamente factível e, no melhor dos casos, tal certificado da CA já pode existir.
2. Lide com as coisas como elas são agora, o que fornece uma maneira de as pessoas verem uma descrição do motivo pelo qual elas não estão chegando ao site em questão.
3. Altere sua reescrita para impedir que eles recebam uma página da Web. Em vez de enviá-los para uma página da Web, "coma" a consulta com rpz-drop. , CNAME . (NXDOMAIN) ou CNAME *. (NODATA).
4. Escolha um endereço IP que sempre recusará a conexão da porta 443 e forneça um registro A que sugira o que está acontecendo no nível da política. Peça para reescrever CNAME point para este registro. Isso, pelo menos, dará a uma pessoa técnica algum tipo de migalha para encontrar quando começar a solução de problemas. Obviamente, essas pessoas técnicas estarão em minoria, mas é melhor que nada.

Um exemplo de # 4 seria algo assim:

# RPZ zone file
$ORIGIN example.rpz.
badsite IN CNAME filtered-malware-site.example.com.

# normal zone file
$ORIGIN example.com.
filtered-malware-site IN A 203.0.113.1