Salta el contingut

AP0103 — DNS Xifrat i Privadesa: DNS over TLS i DNS over HTTPS

De què va aquesta activitat

El DNS tradicional (Do53, port 53 UDP/TCP) viatja en clar. Qualsevol que estigui al mig de la comunicació (l'ISP, un administrador de xarxa, un atacant fent MITM en una WiFi pública) pot llegir tots els dominis que visites encara que després la web sigui HTTPS. El DNSSEC —que treballeu a l'AP0104— protegeix la integritat (que ningú falsifiqui la resposta), però no la confidencialitat: la consulta continua sent visible. Aquí atacarem justament aquest forat amb DNS over TLS (DoT) i DNS over HTTPS (DoH), i acabarem amb la visió blue team: per què el DNS xifrat també és un problema per a qui ha de defensar una xarxa.

Objectius

  • Demostrar la fuita de privadesa del DNS en clar capturant tràfic real.
  • Configurar un client amb DNS over TLS (DoT) i verificar que el tràfic queda xifrat.
  • Configurar DNS over HTTPS (DoH) i comparar-lo amb DoT.
  • Muntar un resolver propi xifrat amb BIND9 (≥ 9.18).
  • Analitzar, des del punt de vista defensiu, els riscos del DNS xifrat (evasió del filtratge corporatiu, C2 de malware) i aprendre a detectar-lo i bloquejar-lo.

Requisits

  • Una Ubuntu Server 22.04 (BIND 9.18, systemd-resolved) amb accés a Internet.
  • Opcionalment, una segona màquina (o el vostre client) per fer de client contra el resolver propi.
  • Eines: tcpdump, wireshark (o tshark), dig/kdig (sudo apt install bind9-dnsutils knot-dnsutils tcpdump).

Instruccions

  • L'activitat és d'aprofundiment i, per tant, voluntària.
  • És de realització individual.
  • Cal justificar les respostes amb captures de pantalla. Si la captura no té cap valor que la identifiqui, cal que es vegi el fons d'escriptori o un editor amb el vostre nomcognom.

Temps estimat: ~150 minuts

Comparativa dels tres modes

flowchart LR
    subgraph clar["Do53 — port 53 (EN CLAR)"]
        A[Client] -->|example.com?| B[Resolver]
    end
    subgraph dot["DoT — port 853 (TLS)"]
        C[Client] -->|TLS xifrat| D[Resolver]
    end
    subgraph doh["DoH — port 443 (HTTPS)"]
        E[Client] -->|HTTPS, indistingible del web| F[Resolver]
    end
Mode Port Transport Qui pot llegir la consulta? Es distingeix a la xarxa?
Do53 53 UDP/TCP en clar Qualsevol al camí Sí (port 53)
DoT 853 TLS Ningú (només extrems) Sí (port 853 dedicat)
DoH 443 HTTPS Ningú (només extrems) No (es barreja amb tot el tràfic web)

Part 1 — El problema: DNS en clar (25 min)

Obriu una captura filtrant el port 53 mentre feu unes quantes consultes:

# En una terminal, captureu
sudo tcpdump -i any -n port 53 -w /tmp/do53.pcap &

# En una altra, genereu consultes
dig +short www.wikipedia.org
dig +short banca-exemple.cat
dig +short salut-exemple.cat

# Atureu la captura (Ctrl+C al tcpdump) i obriu-la
wireshark /tmp/do53.pcap

A Wireshark, apliqueu el filtre dns i observeu el camp Queries → Name.

Q1 — Fuita de privadesa

  1. Es veuen en text pla els dominis que heu consultat? Feu-ne una captura.
  2. Encara que després navegueu per HTTPS, quina informació sobre vosaltres continua sent visible només amb el DNS?
  3. Qui, dins del camí de xarxa, podria recollir aquest historial (penseu en una WiFi d'aeroport)?

Part 2 — DNS over TLS (DoT) com a client (30 min)

Configurarem systemd-resolved perquè resolgui contra un resolver públic amb DoT (Cloudflare 1.1.1.1, o Quad9 9.9.9.9).

Editeu /etc/systemd/resolved.conf:

[Resolve]
DNS=1.1.1.1#cloudflare-dns.com 1.0.0.1#cloudflare-dns.com
DNSOverTLS=yes

El sufix #cloudflare-dns.com és el nom del certificat que s'ha de validar: sense verificar el nom, un MITM podria suplantar el resolver.

Apliqueu i comproveu:

sudo systemctl restart systemd-resolved
resolvectl status        # ha de mostrar "+DNSOverTLS" i el servidor 1.1.1.1

Ara captureu de nou, però al port 853:

sudo tcpdump -i any -n port 853 -w /tmp/dot.pcap &
resolvectl query www.wikipedia.org
# Ctrl+C i obriu a Wireshark

Q2 — Verificació del xifratge

  1. Al .pcap del port 853, hi veieu el nom del domini o només un handshake TLS + dades xifrades (Application Data)? Captura.
  2. Feu ara sudo tcpdump -n port 53 i torneu a consultar: ja no hauria d'aparèixer res pel 53. Per què?
  3. Quin avantatge i quin inconvenient té que DoT faci servir un port dedicat (853)?
Alternativa amb stubby

Si preferiu no dependre de systemd-resolved, stubby és un stub resolver DoT. sudo apt install stubby, configureu upstream_recursive_servers a /etc/stubby/stubby.yml i feu que el sistema apunti a 127.0.0.1.

Part 3 — DNS over HTTPS (DoH) com a client (25 min)

DoH encapsula el DNS dins HTTPS (443), de manera que es confon amb qualsevol navegació web. Usarem cloudflared com a proxy-DNS local.

# Descarregueu cloudflared (paquet .deb oficial per a la vostra arquitectura)
sudo cloudflared proxy-dns --port 5353 \
  --upstream https://1.1.1.1/dns-query &

# Consulteu contra el proxy local
dig @127.0.0.1 -p 5353 +short www.wikipedia.org

Captureu ara el port 443 cap al resolver mentre consulteu:

sudo tcpdump -i any -n host 1.1.1.1 and port 443 -w /tmp/doh.pcap &
dig @127.0.0.1 -p 5353 www.wikipedia.org

Q3 — DoT vs DoH

  1. A la captura de DoH, quin protocol identifica Wireshark (TLS/HTTP2)? Es distingeix d'una navegació web normal?
  2. Ompliu la taula comparant Do53 / DoT / DoH segons: port, què es veu a la captura, i facilitat per a un administrador de bloquejar-lo.
  3. També podeu activar DoH directament al Firefox (Configuració → Privadesa → DNS sobre HTTPS). Comproveu-ho i captureu.

Part 4 — Munta el teu resolver xifrat amb BIND9 (30 min)

A diferència de la PR0101 (on munteu un servidor autoritatiu complet), aquí l'objectiu és només l'extrem xifrat: convertir BIND en un resolver que escolti per DoT i DoH. Requereix BIND ≥ 9.18 (la de Ubuntu 22.04 ja ho és: named -v).

Genereu un certificat (autofirmat per al laboratori):

sudo mkdir -p /etc/bind/keys
sudo openssl req -x509 -newkey rsa:2048 -nodes -days 365 \
  -keyout /etc/bind/keys/privkey.pem \
  -out /etc/bind/keys/fullchain.pem \
  -subj "/CN=dns.exemple.local"
sudo chown -R bind:bind /etc/bind/keys

Afegiu a /etc/bind/named.conf.options:

tls local-tls {
    key-file "/etc/bind/keys/privkey.pem";
    cert-file "/etc/bind/keys/fullchain.pem";
};

options {
    // ... les vostres opcions habituals (recursion, allow-query...) ...

    listen-on port 853  tls local-tls { any; };              // DoT
    listen-on port 443  tls local-tls http default { any; }; // DoH
};

Recarregueu i proveu des del client (amb kdig, del paquet knot-dnsutils):

sudo named-checkconf && sudo systemctl restart named

# DoT contra el vostre servidor
kdig +tls @IP_SERVIDOR www.exemple.local

# DoH contra el vostre servidor
kdig +https @IP_SERVIDOR www.exemple.local

Q4 — Resolver propi

  1. Adjunteu la sortida de kdig +tls i kdig +https funcionant contra el vostre servidor.
  2. Per què en producció no faríeu servir un certificat autofirmat? Quin problema tindria el client?
  3. En què es diferencia aquesta pràctica de la PR0101? (Pista: aquí no definiu zones autoritatives, us centreu en el transport xifrat.)

Part 5 — Blue team: riscos i control del DNS xifrat (40 min)

El DNS xifrat és bo per a la privadesa de l'usuari, però per a qui defensa una xarxa corporativa és una arma de doble tall: evita el filtratge DNS (RPZ, sinkholes, Pi-hole) i el malware modern l'utilitza per amagar el seu canal de comandament i control (C2) dins de tràfic HTTPS legítim.

El problema

Si un lloc de treball activa DoH cap a un resolver extern, totes les proteccions basades en DNS de l'empresa deixen de veure-hi res. Un ransomware pot resoldre el seu domini de C2 per DoH i passar desapercebut.

Tècniques de detecció i control (sempre en xarxes pròpies i autoritzades):

# 1) Bloquejar DoT sortint (port 853 és dedicat → fàcil)
sudo iptables -A FORWARD -p tcp --dport 853 -j REJECT

# 2) Bloquejar per IP els resolvers DoH/DoT públics coneguts
#    (Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9 9.9.9.9, ...)
sudo iptables -A FORWARD -p tcp -d 1.1.1.1 --dport 443 -j REJECT
sudo iptables -A FORWARD -p tcp -d 8.8.8.8 --dport 443 -j REJECT
sudo iptables -A FORWARD -p tcp -d 9.9.9.9 --dport 443 -j REJECT

Bloqueig de la descoberta automàtica de DoH de Firefox mitjançant el domini canari, servint-lo amb RPZ al vostre BIND (tècnica que amplieu a l'AP0104):

// A la zona RPZ: respondre NXDOMAIN al canari desactiva DoH a Firefox
use-application-dns.net    CNAME    .   ;

Q5 — Anàlisi defensiva

  1. Per què DoT (853) és molt més fàcil de bloquejar que DoH (443)? Quina propietat de DoH ho complica?
  2. Quines tres estratègies faríeu servir per detectar/impedir DoH no autoritzat en una xarxa corporativa? (Penseu en: llistes d'IP, inspecció de SNI TLS, domini canari, forçar un resolver intern.)
  3. Argumenteu el dilema ètic: privadesa de l'usuari vs. capacitat de defensa i control parental/corporatiu. No hi ha resposta única — justifiqueu la vostra.

Lliurament

Un document (PDF) amb:

  1. Captures de les Parts 1–4 (Do53 en clar, DoT xifrat, DoH, i el resolver propi amb kdig +tls/+https).
  2. La taula comparativa Do53 / DoT / DoH completada.
  3. Les respostes a Q1–Q5, amb l'anàlisi ètica final.

Relació amb altres continguts