☰

Errores de Certificado en "redireccionamiento" en DNS RPZ de https/ssl

tag-icon • tag-icon domain-name-system https redirection rpz dns-firewall
Errores de Certificado en "redireccionamiento" en DNS RPZ de https/ssl

Configuré un DNS RPZ donde "redirijo" a los usuarios a un jardín amurallado usando registros DNS RPZ cuando los usuarios intentan acceder a una lista de sitios incorrectos.

Digamos que un usuario intenta acceder a badsite.com. La redirección a mi jardín amurallado para conexiones http funciona, pero para conexiones https causa errores de certificado porque la URL en el navegador sigue siendo la misma (badsite.com) pero la IP resuelta se conecta a mi jardín amurallado (walledgarden.example.com).

¿Hay alguna forma de resolver los errores de certificado al utilizar DNS RPZ para la redirección en conexiones https?

Respuesta1

Por un momento, quiero que finjas que eres un autor de malware que ha comprometido con éxito los servidores DNS de tu empresa. Está intentando utilizar DNS para proporcionar direcciones IP falsas cada vez que alguien intenta visitar un banco. Desafortunadamente, no es posible hacer que esas confusas advertencias del navegador desaparezcan cuando se invoca HTTPS.

Eso es básicamente con lo que nos pides que te ayudemos. Sus intenciones son benignas en comparación con las de este supuesto autor de malware, pero eso no cambia el hecho de que la tecnología está funcionando según lo previsto aquí.No se puede diseñar seguridad en torno a la intención.

Dado que la acción de la política ocurre en el nivel DNS, no hay forma de saber si el usuario está usando HTTP o HTTPS en el momento en que se envía la consulta. Lo único que puedes controlar es si vas a devolver o no una dirección IP y cuál es esa dirección IP.

Una vez que haya llegado a este punto, este es un escenario básico de secuestro de HTTPS. Se aplican todas las mismas reglas. Si está en condiciones de manipular las CA confiables, puede manipular los navegadores. Aparte de eso, no hay dados.

Tienes cuatro opciones aquí:

  1. Siga la sugerencia de sebix en los comentarios: envíe un certificado CA a cada estación de trabajo que estará sujeta a esta protección RPZ. Si se trata de una empresa, es perfectamente factible y, en el mejor de los casos, es posible que ya exista dicho certificado de CA.
  2. Trate las cosas como están ahora, lo que proporciona una manera para que las personas vean una descripción de por qué no acceden al sitio en cuestión.
  3. Cambie su reescritura para evitar que obtengan una página web. En lugar de enviarlos a una página web, "coma" la consulta con rpz-drop., CNAME .(NXDOMAIN) o CNAME *.(NODATA).
  4. Elija una dirección IP que siempre rechace la conexión del puerto 443 y proporciónele un Aregistro que sugiera lo que está sucediendo a nivel de política. Haga que su reescritura CNAMEapunte a este disco. Esto al menos le dará al técnico algún tipo de ruta de navegación para encontrar cuando comience a solucionar problemas. Obviamente estos técnicos serán una minoría, pero es mejor que nada.

Un ejemplo del número 4 sería algo como esto:

# 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

información relacionada