☰

Erros de certificado no "redirecionamento" no DNS RPZ de https/ssl

tag-icon • tag-icon domain-name-system https redirection rpz dns-firewall
Erros de certificado no "redirecionamento" no DNS RPZ de https/ssl

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

Digamos que um usuário tente acessar badsite.com. O redirecionamento para meu jardim murado para conexões http funciona, mas para conexões https 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 DNS RPZ para redirecionamento em conexões https?

Responder1

Por um momento, quero que você finja que é um autor de malware que comprometeu com sucesso os servidores DNS da sua empresa. Você está tentando usar o DNS para fornecer 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 o HTTPS é invocado.

É basicamente com isso 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 conforme planejado aqui.Você não pode projetar segurança em torno da intenção.

Como a ação da política 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 retornará ou não um endereço IP e qual é esse endereço IP.

Quando você chegar a este ponto, este é um cenário básico de sequestro de HTTPS. Todas as mesmas regras se aplicam. Se você estiver em condições 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 CA para cada estação de trabalho que estará sujeita a esta proteção RPZ. Se for uma empresa, é perfeitamente viável e, na melhor das hipóteses, esse certificado CA já pode existir.
  2. Lide com as coisas como elas estão agora, o que fornece uma maneira para as pessoas verem uma descrição do motivo pelo qual não estão acessando o site em questão.
  3. Altere sua reescrita para evitar que eles obtenham 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 Aregistro que sugira o que está acontecendo no nível da política. Faça com que sua reescrita CNAMEaponte para este registro. Isso pelo menos dará ao técnico algum tipo de localização para encontrar quando começar a solucionar problemas. Obviamente estes técnicos serão minoria, mas é melhor que nada.

Um exemplo de nº 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

informação relacionada