{"id":97349,"date":"2020-10-17T14:42:14","date_gmt":"2020-10-17T12:42:14","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/minimizacziya-riskov-ispolzovaniya-dns-over-tls-dot-i-dns-over-https-doh"},"modified":"2020-10-17T14:42:14","modified_gmt":"2020-10-17T12:42:14","slug":"minimizacziya-riskov-ispolzovaniya-dns-over-tls-dot-i-dns-over-https-doh","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/minimizacziya-riskov-ispolzovaniya-dns-over-tls-dot-i-dns-over-https-doh","title":{"rendered":"Minimizaci\u00f3n de los riesgos del uso de DNS-over-TLS (DoT) y DNS-over-HTTPS (DoH)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Minimizaci\u00f3nMinimizaci\u00f3n de riesgos en el uso de DoH y DoT<\/p>\n

Protecci\u00f3n contra DoH y DoT<\/h2>\n

\u00bfControla su tr\u00e1fico DNS? Las organizaciones invierten mucho tiempo, dinero y esfuerzo en asegurar sus redes. Sin embargo, una de las \u00e1reas que a menudo no recibe la atenci\u00f3n adecuada es el DNS. <\/p>\n

Una buena visi\u00f3n general de los riesgos que presenta el DNS es la presentaci\u00f3n de Verisign<\/a><\/noindex> en la conferencia Infosecurity. <\/p>\n

\"Minimizaci\u00f3nEl 31% de las familias de malware encuestadas utilizaron DNS para el intercambio de claves. Las conclusiones del estudio<\/p>\n

El 31% de las familias de malware encuestadas utilizaron DNS para el intercambio de claves.<\/p>\n

El problema es serio. Seg\u00fan el laboratorio de investigaci\u00f3n Palo Alto Networks Unit 42, aproximadamente el 85% de los malware utilizan DNS para establecer un canal de control y gesti\u00f3n, lo que permite a los atacantes introducir f\u00e1cilmente malware en su red y robar datos. Desde su creaci\u00f3n, el tr\u00e1fico DNS ha sido en su mayor\u00eda no cifrado y f\u00e1cilmente analizable por mecanismos de protecci\u00f3n NGFW. <\/p>\n

Han aparecido nuevos protocolos para DNS, destinados a mejorar la privacidad de las conexiones DNS. Son respaldados activamente por los principales proveedores de navegadores y otros proveedores de software. Pronto, en las redes corporativas, se observar\u00e1 un aumento del tr\u00e1fico DNS cifrado. El tr\u00e1fico DNS cifrado que no se analiza adecuadamente y se permite representa una amenaza para la seguridad de la empresa. Por ejemplo, una de esas amenazas son los ransomware, que utilizan DNS para el intercambio de claves de cifrado. Los atacantes actualmente exigen rescates de varios millones de d\u00f3lares para restaurar el acceso a sus datos. En la empresa Garmin, por ejemplo, pagaron 10 millones de d\u00f3lares.<\/p>\n

Con la configuraci\u00f3n correcta, los NGFW pueden prohibir o proteger el uso de DNS-over-TLS (DoT) y pueden utilizarse para prohibir el uso de DNS-over-HTTPS (DoH), lo que permite analizar todo el tr\u00e1fico DNS en su red.<\/p>\n

\u00bfQu\u00e9 es DNS cifrado?<\/h2>\n

Qu\u00e9 es DNS<\/p>\n

El sistema de nombres de dominio (DNS) convierte nombres de dominio legibles por humanos (por ejemplo, la direcci\u00f3n www.paloaltonetworks.com<\/a><\/noindex> ) a direcciones IP (por ejemplo, 34.107.151.202). Cuando un usuario ingresa un nombre de dominio en el navegador web, el navegador env\u00eda una consulta DNS al servidor DNS solicitando la direcci\u00f3n IP asociada con ese nombre de dominio. En respuesta, el servidor DNS devuelve la direcci\u00f3n IP que utilizar\u00e1 este navegador.<\/p>\n

Las consultas y respuestas DNS se env\u00edan a trav\u00e9s de la red como texto plano en formato no cifrado, lo que las hace vulnerables a la espionaje o a la modificaci\u00f3n de respuestas que desv\u00eden al navegador a servidores maliciosos. El cifrado de DNS dificulta el seguimiento de las consultas DNS o su modificaci\u00f3n durante la transmisi\u00f3n. El cifrado de las consultas y respuestas DNS te protege contra ataques de tipo Man-in-the-Middle, cumpliendo al mismo tiempo las mismas funciones que el protocolo DNS tradicional (sistema de nombres de dominio) con texto claro. <\/p>\n

En los \u00faltimos a\u00f1os, se han implementado dos protocolos de cifrado DNS:<\/p>\n

    \n
  1. \n

    DNS-over-HTTPS (DoH)<\/p>\n<\/li>\n

  2. \n

    DNS-over-TLS (DoT) <\/p>\n<\/li>\n<\/ol>\n

    Estos protocolos tienen una caracter\u00edstica com\u00fan: ocultan intencionadamente las consultas DNS de cualquier intercepci\u00f3n\u2026 incluidos los responsables de seguridad de la organizaci\u00f3n. Los protocolos utilizan principalmente el protocolo TLS (Transport Layer Security) para establecer una conexi\u00f3n cifrada entre el cliente que realiza las solicitudes y el servidor que resuelve las solicitudes DNS, a trav\u00e9s de un puerto que normalmente no se usa para tr\u00e1fico DNS.<\/p>\n

    La privacidad de las consultas DNS es una gran ventaja de estos protocolos. Sin embargo, crean problemas para los responsables de seguridad, que deben supervisar el tr\u00e1fico de la red y detectar y bloquear conexiones maliciosas. Dado que los protocolos difieren en su implementaci\u00f3n, los m\u00e9todos de an\u00e1lisis tambi\u00e9n variar\u00e1n entre DoH y DoT.<\/p>\n

    DNS over HTTPS (DoH)<\/h2>\n

    \"Minimizaci\u00f3nDNS dentro de HTTPS<\/p>\n

    DoH utiliza el conocido puerto 443 para HTTPS, para el cual se especifica en el RFC que la tarea es \"mezclar el tr\u00e1fico de DoH con otro tr\u00e1fico HTTPS en la misma conexi\u00f3n\", \"dificultando el an\u00e1lisis del tr\u00e1fico DNS\" y, de esta manera, evadiendo las medidas de control corporativo ( RFC 8484 DoH, secci\u00f3n 8.1<\/a><\/noindex> ). El protocolo DoH utiliza cifrado TLS y la sintaxis de consultas proporcionada por los est\u00e1ndares comunes de HTTPS y HTTP\/2, a\u00f1adiendo consultas y respuestas DNS sobre las solicitudes est\u00e1ndar HTTP.<\/p>\n

    Riesgos asociados con DoH<\/h2>\n

    Si no puede distinguir entre el tr\u00e1fico HTTPS normal y las solicitudes DoH, las aplicaciones dentro de su organizaci\u00f3n pueden (y lo har\u00e1n) eludir la configuraci\u00f3n local de DNS, redirigiendo las solicitudes a servidores externos que responden a las solicitudes DoH, lo que elude cualquier monitoreo, es decir, destruye la posibilidad de controlar el tr\u00e1fico DNS. En ideal, debe controlar DoH utilizando funciones de descifrado HTTPS. <\/p>\n

    Y Google y Mozilla han implementado capacidades de DoH<\/a><\/noindex> en la \u00faltima versi\u00f3n de sus navegadores, y ambas empresas trabajan en la posibilidad de usar DoH por defecto para todas las solicitudes DNS. Microsoft tambi\u00e9n est\u00e1 desarrollando planes<\/a><\/noindex> para integrar DoH en sus sistemas operativos. Un inconveniente es que no solo empresas respetables de software, sino tambi\u00e9n atacantes han comenzado a utilizar DoH como medio para eludir las medidas tradicionales del firewall corporativo. (Por ejemplo, consulte los siguientes art\u00edculos: PsiXBot ahora utiliza Google DoH<\/a><\/noindex> , PsiXBot contin\u00faa evolucionando con una infraestructura DNS actualizada<\/a><\/noindex> y an\u00e1lisis del backdoor Godlua<\/a><\/noindex> .) En cualquier caso, tanto el tr\u00e1fico DoH benigno como el malicioso permanecer\u00e1n sin ser detectados, dejando a la organizaci\u00f3n ciega al uso malicioso de DoH como canal para el control de malware (C2) y el robo de datos confidenciales.<\/p>\n

    Asegurando la visibilidad y el control del tr\u00e1fico DoH<\/h2>\n

    Como mejor soluci\u00f3n para controlar DoH, recomendamos configurar en NGFW el descifrado del tr\u00e1fico HTTPS y la bloqueo del tr\u00e1fico DoH (nombre de la aplicaci\u00f3n: dns-over-https). <\/p>\n

    Primero, aseg\u00farese de que el NGFW est\u00e9 configurado para descifrar HTTPS, de acuerdo con la gu\u00eda de mejores pr\u00e1cticas de descifrado<\/a><\/noindex>.<\/p>\n

    En segundo lugar, cree una regla para el tr\u00e1fico de la aplicaci\u00f3n 'dns-over-https', como se muestra a continuaci\u00f3n:<\/p>\n

    \"Minimizaci\u00f3nRegla de Palo Alto Networks NGFW para bloquear DNS-over-HTTPS<\/p>\n

    Como alternativa intermedia (si su organizaci\u00f3n no ha implementado completamente el descifrado HTTPS), el NGFW se puede configurar para aplicar la acci\u00f3n 'denegar' al ID de aplicaci\u00f3n 'dns-over-https', pero el efecto estar\u00e1 limitado a bloquear ciertos servidores DoH bien conocidos por su nombre de dominio, ya que sin el descifrado HTTPS, el tr\u00e1fico DoH no puede ser verificado completamente (ver.  Applipedia de Palo Alto Networks<\/a><\/noindex>   y busque la frase 'dns-over-https').<\/p>\n

    DNS sobre TLS (DoT)<\/h2>\n

    \"Minimizaci\u00f3nDNS dentro de TLS<\/p>\n

    Mientras que el protocolo DoH intenta mezclarse con otro tr\u00e1fico en el mismo puerto, DoT, por el contrario, utiliza por defecto un puerto especial reservado solo para este prop\u00f3sito, incluso prohibiendo espec\u00edficamente el uso del mismo puerto para tr\u00e1fico DNS no cifrado tradicional ( RFC 7858, Secci\u00f3n 3.1<\/a><\/noindex> ).<\/p>\n

    El protocolo DoT utiliza el protocolo TLS para proporcionar cifrado, encapsulando las solicitudes est\u00e1ndar del protocolo DNS, con tr\u00e1fico que utiliza el bien conocido puerto 853 ( RFC 7858, secci\u00f3n 6<\/a><\/noindex> ). El protocolo DoT fue dise\u00f1ado para facilitar a las organizaciones bloquear el tr\u00e1fico a trav\u00e9s del puerto, ya sea aceptando su uso, pero incluyendo la descifrado en ese puerto.<\/p>\n

    Riesgos asociados con DoT<\/h2>\n

    Google implement\u00f3 DoT en su cliente Android 9 Pie y versiones posteriores<\/a><\/noindex> , teniendo la configuraci\u00f3n autom\u00e1tica de usar DoT, si est\u00e1 disponible, activada por defecto. Si ha evaluado los riesgos y est\u00e1 listo para utilizar DoT a nivel organizacional, los administradores de red deben permitir expl\u00edcitamente el tr\u00e1fico saliente en el puerto 853 a trav\u00e9s de su per\u00edmetro para este nuevo protocolo.<\/p>\n

    Asegurando visibilidad y control del tr\u00e1fico DoT<\/h2>\n

    Como mejor pr\u00e1ctica para el control de DoT, recomendamos cualquiera de las siguientes, seg\u00fan los requisitos de su organizaci\u00f3n:<\/p>\n