Co-authored-by: Crowdin Bot <support+bot@crowdin.com> Co-authored-by: Jonah Aragon <jonah@triplebit.net>
21 KiB
title | icon |
---|---|
Resumen DNS | material/dns |
El Sistema de Nombres de Dominio es el 'directorio telefónico del Internet'. El DNS traduce los nombres de dominio a direcciones IP para que los navegadores y otros servicios puedan cargar los recursos de Internet, a través de una red descentralizada de servidores.
¿Qué es el DNS?
Cuando visitas un sitio web, se devuelve una dirección numérica. Por ejemplo, cuando visitas privacyguides.org
, la dirección 192.98.54.105
es devuelta.
DNS ha existido desde los primeros días de Internet. Las solicitudes DNS realizadas desde y hacia servidores DNS no son generalmente cifradas. En un entorno residencial, el cliente recibe servidores del ISP a través de DHCP.
Las solicitudes de DNS sin cifrar pueden ser fácilmente vigiladas y modificadas en tránsito. En algunas partes del mundo, a los ISP se les ordena que hagan un filtrado de DNS primitivo. Cuando se solicita la dirección IP de un dominio que está bloqueado, es posible que el servidor no responda o lo haga con una dirección IP diferente. Como el protocolo DNS no está encriptado, el ISP (o cualquier operador de red) puede utilizar DPI para controlar las solicitudes. Los ISP también pueden bloquear las solicitudes en función de características comunes, independientemente del servidor DNS que se utilice. El DNS no cifrado siempre utiliza el puerto 53 y siempre utiliza UDP.
A continuación, discutimos y proporcionamos un tutorial para probar lo que un observador externo puede ver usando DNS regulares sin encriptar y DNS encriptado.
DNS sin cifrado
-
Usando
tshark
(parte del proyecto Wireshark) podemos monitorear y registrar el flujo de paquetes de Internet. Este comando registra los paquetes que cumplen las reglas especificadas:tshark -w /tmp/dns.pcap udp port 53 and host 1.1.1.1 or host 8.8.8.8
-
Entonces podemos usar
dig
(Linux, macOS, etc) onslookup
(Windows) para enviar la búsqueda DNS a ambos servidores. Software como los navegadores web hacen estas búsquedas automáticamente, a menos que estén configurados para usar DNS cifrado.=== "Linux, macOS"
``` dig +noall +answer privacyguides.org @1.1.1.1 dig +noall +answer privacyguides.org @8.8.8.8 ```
=== "Windows"
``` nslookup privacyguides.org 1.1.1.1 nslookup privacyguides.org 8.8.8.8 ```
-
A continuación, queremos analizar los resultados:
=== "Wireshark"
``` wireshark -r /tmp/dns.pcap ```
=== "tshark"
``` tshark -r /tmp/dns.pcap ```
Si ejecutas el comando Wireshark anterior, el panel superior muestra los "frames", y el panel inferior muestra todos los datos sobre el frame seleccionado. Las soluciones empresariales de filtrado y monitorización (como las adquiridas por los gobiernos) pueden realizar el proceso de forma automática, sin interacción humana, y pueden agregar esas tramas para producir datos estadísticos útiles para el observador de la red.
No. | Tiempo | Fuente | Destino | Protocolo | Duración | Información |
---|---|---|---|---|---|---|
1 | 0.000000 | 192.0.2.1 | 1.1.1.1 | Almacenamiento en la Nube | 104 | Consulta estándar 0x58ba A privacyguides.org OPT |
2 | 0.293395 | 1.1.1.1 | 192.0.2.1 | Almacenamiento en la Nube | 108 | Respuesta de consulta estándar 0x58ba A privacyguides.org A 198.98.54.105 OPT |
3 | 1.682109 | 192.0.2.1 | 8.8.8.8 | Almacenamiento en la Nube | 104 | Consulta estándar 0xf1a9 A privacyguides.org OPT |
4 | 2.154698 | 8.8.8.8 | 192.0.2.1 | Almacenamiento en la Nube | 108 | Respuesta de consulta estándar 0xf1a9 A privacyguides.org A 198.98.54.105 OPT |
Un observador podría modificar cualquiera de estos paquetes.
¿Qué es "DNS cifrado"?
DNS cifrado puede referirse a uno de un número de protocolos, siendo los más comunes:
DNSCrypt
DNSCrypt fue uno de los primeros métodos de encriptación de consultas DNS. DNSCrypt opera en el puerto 443 y funciona con los protocolos de transporte TCP o UDP. DNSCrypt nunca ha sido enviado al Grupo de Trabajo de Ingeniería en Internet (IETF) ni ha pasado por el proceso de "Request for Comments" (RFC) por lo que no ha sido utilizado ampliamente fuera de unas pocas implementaciones. Como resultado, ha sido sustituido en gran medida por el más popular DNS sobre HTTPS.
DNS sobre TLS (DoT)
DNS sobre TLS es otro método para cifrar la comunicación DNS que se define en RFC 7858. La compatibilidad se implementó por primera vez en Android 9, iOS 14 y en Linux en systemd-resolved en la versión 237. La preferencia en la industria se ha estado alejando del DoT al DoH en los últimos años, ya que el DoT es un protocolo complejo y tiene un cumplimiento variable del RFC en todas las implementaciones que existen. DoT también opera en un puerto dedicado 853 que puede ser bloqueado fácilmente por cortafuegos restrictivos.
DNS sobre HTTPS (DoH)
DNS sobre HTTPS como se define en RFC 8484 empaqueta las consultas en el protocolo HTTP/2 y proporciona seguridad con HTTPS. La compatibilidad se añadió por primera vez en navegadores web como Firefox 60 y Chrome 83.
La implementación nativa de DoH apareció en iOS 14, macOS 11, Microsoft Windows y Android 13 (sin embargo, no estará habilitada por defecto). El soporte general de los escritorios de Linux está a la espera de la implementación de systemd por lo que la instalación de software de terceros sigue siendo necesaria.
¿Qué puede ver un tercero?
En este ejemplo registraremos lo que sucede cuando hacemos una solicitud de DoH:
-
En primer lugar, inicia
tshark
:tshark -w /tmp/dns_doh.pcap -f "tcp port https and host 1.1.1.1"
-
En segundo lugar, hace una petición con
curl
:curl -vI --doh-url https://1.1.1.1/dns-query https://privacyguides.org
-
Después de hacer la solicitud, podemos detener la captura de paquetes con CTRL + C.
-
Analiza los resultados en Wireshark:
wireshark -r /tmp/dns_doh.pcap
Podemos ver el establecimiento de la conexión y enlace TLS que ocurre con cualquier conexión encriptada. Al mirar los paquetes de "datos de aplicación" que siguen, ninguno de ellos contiene el dominio que solicitamos ni la dirección IP devuelta.
¿Por qué no debería utilizar un DNS cifrado?
En los lugares en los que existe el filtrado de Internet (o la censura), visitar recursos prohibidos puede tener sus propias consecuencias, que deberás tener en cuenta en tu modelo de amenazas. Nosotros no sugerimos el uso de DNS encriptados para este propósito. Usa Tor o una VPN en su lugar. Si estás usando una VPN, deberías usar los servidores DNS de tu VPN. Al utilizar una VPN, ya les estás confiando toda tu actividad en la red.
Cuando hacemos una búsqueda en el DNS, generalmente es porque queremos acceder a un recurso. A continuación, hablaremos de algunos de los métodos que pueden revelar tus actividades de navegación incluso cuando se utiliza un DNS cifrado:
Dirección IP
La forma más sencilla de determinar la actividad de navegación podría ser mirar las direcciones IP a las que acceden sus dispositivos. Por ejemplo, si el observador sabe que privacyguides.org
está en 198.98.54.105
, y tu dispositivo solicita datos de 198.98.54.105
, es muy probable que estés visitando Privacy Guides.
Este método sólo es útil cuando la dirección IP pertenece a un servidor que sólo aloja unos pocos sitios web. Tampoco es muy útil si el sitio está alojado en una plataforma compartida (por ejemplo, Github Pages, Cloudflare Pages, Netlify, WordPress, Blogger, etc). Tampoco es muy útil si el servidor está alojado detrás de un proxy inverso, lo cual es muy común en la Internet moderna.
Indicación del Nombre del Servidor (SNI)
La Indicación del Nombre del Servidor se suele utilizar cuando una dirección IP aloja muchos sitios web. Esto podría ser un servicio como Cloudflare, o alguna otra protección de ataque de denegación de servicio.
-
Comienza a capturar de nuevo con
tshark
. Hemos añadido un filtro con nuestra dirección IP para que no captures muchos paquetes:tshark -w /tmp/pg.pcap port 443 and host 198.98.54.105
-
Luego visitamos https://privacyguides.org.
-
Después de visitar el sitio web, queremos detener la captura de paquetes con CTRL + C.
-
A continuación queremos analizar los resultados:
wireshark -r /tmp/pg.pcap
Veremos el establecimiento de la conexión, seguido del enlace TLS para el sitio web de Privacy Guides. Alrededor del marco 5. verás un "Client Hello".
-
Expande el triángulo ▸ junto a cada campo:
▸ Transport Layer Security ▸ TLSv1.3 Record Layer: Handshake Protocol: Client Hello ▸ Handshake Protocol: Client Hello ▸ Extension: server_name (len=22) ▸ Server Name Indication extension
-
Podemos ver el valor SNI que revela el sitio web que estamos visitando. El comando
tshark
puede darte el valor directamente para todos los paquetes que contienen un valor SNI:tshark -r /tmp/pg.pcap -Tfields -Y tls.handshake.extensions_server_name -e tls.handshake.extensions_server_name
Esto significa que incluso si estamos utilizando servidores "DNS cifrados", es probable que el dominio se divulgue a través de SNI. El protocolo TLS v1.3 trae consigo Client Hello Encriptado, que evita este tipo de fugas.
Los gobiernos, en particular de China y Russia, ya han empezado a bloquearlo o han expresado su deseo de hacerlo. Recientemente, Rusia ha comenzado a bloquear sitios web extranjeros que utilizan el estándar HTTP/3. Esto se debe a que el protocolo QUIC que forma parte de HTTP/3 requiere que ClientHello
también esté cifrado.
Protocolo de comprobación del Estado de un Certificado En línea (OCSP)
Otra forma en que tu navegador puede revelar tus actividades de navegación es con el Protocolo de comprobación del Estado de un Certificado En línea. Al visitar un sitio web HTTPS, el navegador puede comprobar si el certificado del sitio web ha sido revocado. Esto se hace generalmente a través del protocolo HTTP, lo que significa que no está cifrado.
La solicitud OCSP contiene el "número de serie" del certificado, que es único. Se envía al "Respondedor OCSP" para comprobar su estado.
Podemos simular lo que haría un navegador utilizando el comando openssl
.
-
Obtén el certificado del servidor y usa
sed
para conservar sólo la parte importante y escribirla en un archivo:openssl s_client -connect privacyguides.org:443 < /dev/null 2>&1 | sed -n '/^-*BEGIN/,/^-*END/p' > /tmp/pg_server.cert
-
Obtén el certificado intermedio. Las Autoridades de Certificación (CA) normalmente no firman un certificado directamente; utilizan lo que se conoce como un certificado "intermedio".
openssl s_client -showcerts -connect privacyguides.org:443 < /dev/null 2>&1 | sed -n '/^-*BEGIN/,/^-*END/p' > /tmp/pg_and_intermediate.cert
-
El primer certificado en
pg_and_intermediate.cert
es en realidad el certificado del servidor del paso 1. Podemos usarsed
de nuevo para borrar hasta la primera instancia de END:sed -n '/^-*END CERTIFICATE-*$/!d;:a n;p;ba' \ /tmp/pg_and_intermediate.cert > /tmp/intermediate_chain.cert
-
Obtén el respondedor OCSP para el certificado del servidor:
openssl x509 -noout -ocsp_uri -in /tmp/pg_server.cert
Nuestro certificado muestra el respondedor del certificado Lets Encrypt. Si queremos ver todos los detalles del certificado podemos utilizar:
openssl x509 -text -noout -in /tmp/pg_server.cert
-
Inicia la captura de paquetes:
tshark -w /tmp/pg_ocsp.pcap -f "tcp port http"
-
Realiza la solicitud OCSP:
openssl ocsp -issuer /tmp/intermediate_chain.cert \ -cert /tmp/pg_server.cert \ -text \ -url http://r3.o.lencr.org
-
Abre la captura:
wireshark -r /tmp/pg_ocsp.pcap
Habrá dos paquetes con el protocolo "OCSP": una "Solicitud" y una "Respuesta". Para la "Solicitud" podemos ver el "número de serie" expandiendo el triángulo ▸ al lado de cada campo:
▸ Online Certificate Status Protocol ▸ tbsRequest ▸ requestList: 1 item ▸ Request ▸ reqCert serialNumber
Para la "Respuesta" también podemos ver el "número de serie":
▸ Online Certificate Status Protocol ▸ responseBytes ▸ BasicOCSPResponse ▸ tbsResponseData ▸ responses: 1 item ▸ SingleResponse ▸ certID serialNumber
-
O usa
tshark
para filtrar los paquetes por el número de serie:tshark -r /tmp/pg_ocsp.pcap -Tfields -Y ocsp.serialNumber -e ocsp.serialNumber
Si el observador de red tiene el certificado público, que está disponible públicamente, puede hacer coincidir el número de serie con ese certificado y, por lo tanto, determinar el sitio que estás visitando a partir de ese. El proceso puede automatizarse y asociar las direcciones IP con los números de serie. También es posible consultar los registros de Certificate Transparency para conocer el número de serie.
¿Debería utilizar un DNS cifrado?
Hemos elaborado este diagrama de flujo para describir cuándo deberías usar el DNS cifrado:
graph TB
Comienzo[Start] --> anonymous{¿Tratando de ser<br> anónimo?}
anonymous--> | Sí | tor(Usa Tor)
anonymous --> | No | censorship{¿Evitando la<br> censura?}
censorship --> | Sí | vpnOrTor(Usa una<br> VPN o Tor)
censorship --> | No | privacy{¿Quieres privacidad<br> del ISP?}
privacy --> | Sí | vpnOrTor
privacy --> | No | obnoxious{¿El ISP hace<br> odiosas<br> redirecciones?}
obnoxious --> | Sí | encryptedDNS(Usa<br> DNS cifrado<br> con terceros)
obnoxious --> | No | ispDNS{¿El ISP soporta<br> DNS cifrado?}
ispDNS --> | Sí | useISP(Usa<br> DNS cifrado<br> con ISP)
ispDNS --> | No | nothing(No hagas nada)
El DNS cifrado con un tercero solo debe usarse para evitar redirecciones y el bloqueo básico de DNS cuando puedas estar seguro de que no habrá consecuencias o estés interesado en un proveedor que realice un filtrado rudimentario.
Lista de servidores DNS recomendados{.md-button}
¿Qué es DNSSEC?
Las extensiones de seguridad para el sistema de nombres de dominio (DNSSEC) son una función del DNS que autentifica las respuestas a las búsquedas de nombres de dominio. No proporciona protecciones de privacidad para esas búsquedas, sino que evita que los atacantes manipulen o envenenen las respuestas a las solicitudes de DNS.
En otras palabras, DNSSEC firma digitalmente los datos para ayudar a garantizar su validez. Para garantizar una búsqueda segura, la firma se produce en todos los niveles del proceso de búsqueda del DNS. Como resultado, todas las respuestas del DNS son de confianza.
El proceso de firma de DNSSEC es similar al de alguien que firma un documento legal con un bolígrafo; esa persona firma con una firma única que nadie más puede crear, y un perito judicial puede mirar esa firma y verificar que el documento fue firmado por esa persona. Estas firmas digitales garantizan que los datos no han sido manipulados.
DNSSEC implementa una política de firma digital jerárquica en todas las capas del DNS. Por ejemplo, en el caso de una búsqueda en privacyguides.org
, un servidor DNS raíz firmaría una clave para el servidor de nombres .org
, y el servidor de nombres .org
firmaría entonces una clave para el servidor de nombres autoritativo privacyguides.org
.
Adaptado de DNS Security Extensions (DNSSEC) overview por Google y DNSSEC: An Introduction por Cloudflare, ambos licensiados bajo CC BY 4.0.
¿Qué es la minimización de QNAME?
Un QNAME es un "nombre cualificado", por ejemplo privacyguides.org
. La minimización de QNAME reduce la cantidad de información enviada desde el servidor DNS al servidor de nombres autoritativo.
En lugar de enviar todo el dominio privacyguides.org
, la minimización de QNAME significa que el servidor DNS pedirá todos los registros que terminen en .org
. Una descripción técnica más detallada se encuentra en RFC 7816.
¿Qué es la Subred del Cliente EDNS (ECS)?
La Subred de Cliente EDNS es un método para que un resolvedor DNS recursivo especifique una subred para el host o cliente que está realizando la consulta DNS.
Su objetivo es "acelerar" la entrega de datos dando al cliente una respuesta que pertenece a un servidor que está cerca de él, como una red de distribución de contenidos, que se utilizan a menudo en la transmisión de vídeo y el servicio de aplicaciones web de JavaScript.
Esta característica tiene un coste de privacidad, ya que indica al servidor DNS cierta información sobre la ubicación del cliente.