enchufado
   RSS
#
Privacidad de consultas DNS (GNU/Linux) 2019-01-20 18:41:09

En los últimos tiempos, parece que se ha puesto de moda y nos han dado la murga desde diversos frentes con el tema HTTPS. Y está bien más que nada en el aspecto de la seguridad de los datos transmitidos y la privacidad, porque en cuanto a lo que se refiere a la verificación de la parte poseedora del certificado, podría ser objeto de discusión.

Y ya que estamos puestos en materia, también deberíamos preocuparnos por un aspecto olvidado y asignatura pendiente en el ámbito de la privacidad como lo es el DNS. Las consultas, por defecto van en plano/sin cifrar, y resultan una suculenta información empresarial que puede servir para definir el perfil de cada persona.

Así pues, en la búsqueda de implementar algo rápido, me topé con éste interesante artículo al respecto de arstechnica que me gustó y cuya lectura recomiendo. A continuación los métodos probados para su consecución, siempre en Debian GNU/Linux testing :)

DNS over HTTPS (DoH!)

Éste método fue el primero que probé por las posibilidades de tenerlo funcionando en un corto espacio de tiempo, y funcionó. Se basa en hacer las peticiones DNS a través de HTTPS. No se requiere autenticación, y de la validación del certificado SSL ya se encargan las CA's. Aquí su uso en Debian (testing):

$ wget https://bin.equinox.io/c/VdrWdbjqyF/cloudflared-stable-linux-amd64.tgz
$ tar -zxvf cloudflared-stable-linux-amd64.tgz
$ cp /etc/resolv.conf{,.bak}
$ echo 'nameserver 127.0.0.1' > /etc/resolv.conf
$ ./cloudflared proxy-dns --upstream https://1.0.0.1/dns-query

Como podemos ver, usamos el cliente de tunneling Argo de Cloudflare y es necesario poner como nameserver nuestro propio host (localhost / 127.0.0.1), puesto que es dónde estará escuchando éste servicio que lanzamos. Como apunte, comentar que nos hemos bajado el binario (a pesar de haber paquete Debian) porque queríamos ver el contenido y poder ejecutarlo manualmente sin necesidad de instalar nada. Al fin y al cabo, se trata de un paquete ajeno a Debian.

La ventaja del mismo es que funciona por puertos web estandar, por lo que seguramente lo podríamos usar allá donde vayamos al no estar bloqueado por firewalls. El inconveniente es que no disponemos del código fuente, y aunque CloudFlare es una empresa de conocida reputación, nos gusta el código de fuente abierta y libre, con auditoria "mundial".

DNS over TLS

Sobre éste método, mis kudos a SrDedo por darse cuenta que el paquete stubby estaba en los repositorios de Debian (en el momento del artículo, al parecer no lo estaba) y por tanto, nos decidiéramos a probarlo.

El método encapsula las consultas DNS en tráfico TCP encriptado. A continuación su instalación y uso en Debian (testing):

$ apt-get install stubby
$ systemctl start stubby
$ cp /etc/resolv.conf{,.bak}
$ echo 'nameserver 127.0.0.1' > /etc/resolv.conf

Su configuración está en formato yaml y puede encontrarse en /etc/stubby/stubby.yml. Por defecto es segura en el sentido que sólo acepta funcionar:

  • En modo estricto (autenticación con upstream obligatoria)
  • En modo seguro (se usa TLS o nada)
  • En modo privado (se requiere privacidad del cliente o nada)
  • Con queries distribuidos en múltiples servidores upstream (round robin en los habilitados)

Las ventajas son que es un proposed IETF standard, que es fácil/ rápido/sencillo en Debian y que usa SPKI para autenticar la conexión con los servidores. El inconveniente es que al funcionar por el puerto 853, puede estar bloqueado por algún firewall (depende de dónde estemos), aunque hay upstreams que permiten usar el puerto 443 (ver el archivo de configuración).

¿Cómo comprobar su funcionamiento?

Basta con, habiendo habilitado uno de los métodos, hagamos un tcpdump en local al puerto 53 y ver que no hay tráfico cuando hacemos requests DNS. Para ver el tráfico del primer método, podemos capturar el tráfico del puerto 443 (aunque costará distinguir tráfico web del dns enrutado por web), y para el segundo método tendremos que capturarlo del puerto 853, que es por donde funciona la vertiente DNS over TLS.

¿Y no hubiéramos acabado antes con DNSSEC?

Son cosas diferentes. DNSSEC se encarga de validar que la respuesta dns proviene de su servidor autoritativo y que no ha sido modificada. Es por tanto, una medida complementaria, pero distinta, a la privacidad. Resulta, por eso, que los servidores upstream de la solución que más nos ha gustado (DNS over TLS con stubby) soportan DNSSEC. Aquí podéis comprobarlo, una vez lo tengáis funcionando, claro está. O para hacerlo manualmente desde consola:

  • dig sigok.verteiltesysteme.net (should return A record)
  • dig sigfail.verteiltesysteme.net (should return SERVFAIL)

Comentarios (0)


Volver al indice

login, admin, form, register