Vai al contenuto

Router portatile per la privacy: DNS-Over-TLS su OpenWrt (LEDE) con Unbound

Oggi condividiamo una guida dettagliata su come configurare DNS-Over-TLS con GL-AR750 scritta da Junade Ali. Se non sai che cos'è DNS-Over-TLS, ecco una breve spiegazione:

Un ISP invadente può raccogliere dati su ogni tua azione su Internet e venderli a inserzionisti e società di marketing. DNS-Over-TLS è un nuovo strumento di sicurezza della navigazione web per proteggere la privacy degli utenti. Crittografa le richieste DNS, impedendo intercettazioni e manipolazioni dei dati DNS tramite attacchi man-in-the-middle.


Per passare direttamente alle istruzioni, scorri alla prossima sezione. Ma io, come un handshake TLS, sono molto prolisso: goditi questa introduzione.

Immagina: sono al ristorante e devo fare una chiamata privata, ma il telefono è scarico. Prendo quello di un amico e compongo il numero, poi esco per tutelare la privacy. Finita la chiamata torno e lo restituisco.

Anche se il telefono non memorizza la conversazione, conserva un registro del numero chiamato di recente. Se l'amico che mi ha prestato il telefono volesse, potrebbe vedere facilmente chi ho chiamato, anche senza conoscere l'argomento della conversazione.

A volte, sapere con chi hai parlato può rivelare moltissimo sulla conversazione: se qualcuno chiama una linea di supporto emotivo o un recuperatore di crediti, probabilmente si può dedurre molto dall'identità del chiamante.

Quando navighiamo su Internet, usiamo la crittografia per proteggere le conversazioni. Collegandoti a un sito tramite HTTPS, un lucchetto verde nel browser indica che la comunicazione è crittografata: per un aggressore tra te e il server del sito è computazionalmente difficile vedere ciò di cui parlate.

Ho già scritto di come, in determinate circostanze, sia possibile rimuovere questa crittografia e delle misure che i siti web possono adottare per impedirlo. Purtroppo esiste un problema molto più fondamentale per la privacy online.

Come è noto in ambito IT, prima che il browser stabilisca una connessione HTTP a un sito web (per esempio cloudflare.com), il client deve eseguire una query DNS per determinare l'indirizzo IP a cui effettuare la connessione HTTP. Lo stesso vale per qualsiasi altro protocollo a livello applicativo quando ti colleghi tramite un nome host anziché un indirizzo IP. Per un'introduzione al DNS, nel nostro centro di apprendimento trovi un articolo sulle basi del DNS.

dns-lookup-diagram

La crittografia esiste da tempo per HTTP, ma solo recentemente è stata standardizzata per DNS. Se non sai se il traffico DNS è crittografato, probabilmente non lo è.

In pratica, quando ti colleghi a un sito HTTPS, anche se la conversazione è crittografata, chi intercetta la connessione vede quale sito cerchi e, secondo la sicurezza del sito, può manipolare la risposta per farti comunicare con un server diverso.

È particolarmente utile per chi intercetta il traffico: dalla rete che gestisce l'hotspot Wi-Fi gratuito e vuole vendere i tuoi dati agli inserzionisti, all'hacker che sorseggia un latte mentre intercetta il traffico, ironicamente vestito con felpa nera e passamontagna.

Passando al resolver DNS di Cloudflare, ottieni una navigazione più veloce e la garanzia che chi gestisce il resolver DNS non venda i dati per mostrarti pubblicità mirata. Tuttavia, anche se Cloudflare Resolver supporta DNS-over-HTTPS e DNS-over-TLS, per assicurare che la connessione tra te e Cloudflare Resolver sia crittografata potresti dover eseguire ulteriori configurazioni, come attivare un client DNS su HTTPS.

Questo articolo spiega come configurare un router OpenWrt per crittografare il traffico in uscita verso Cloudflare Resolver. È particolarmente utile per proteggere il traffico dei dispositivi domestici che potrebbero non supportare protocolli DNS crittografati, come la TV o un tostapane IoT. Sebbene i client locali possano scegliere esplicitamente un resolver DNS diverso da quello del router, molti lo utilizzano per impostazione predefinita.

OpenWrt (LEDE)

IMG-3335-1

Nel weekend prima di scrivere, ho ordinato GL.iNet GL-AR750, router wireless compatto venduto come router da viaggio: funge da ripetitore Wi-Fi e router Wi-Fi tradizionale. Il lato più lungo è circa come il mio indice:

IMG-3360

Non l'ho scelto solo per il formato: include OpenWrt, sistema Linux integrato ideale per router. A maggio 2016 OpenWrt è diventato anche il fork LEDE (Linux Embedded Development Environment), poi riunito al progetto OpenWrt a gennaio 2018.

Se il tuo router non ha LEDE preinstallato, puoi seguire questo articolo con un altro router su cui si può installare OpenWrt; trovi maggiori informazioni nella pagina OpenWrt Support Devices. Tieni presente che, secondo il dispositivo, può comportare rischi.

Supporto DNS-over-TLS, o la sua assenza

Il router che sto provando offre un'opzione per configurare il resolver DNS upstream da utilizzare quando una query non è nella cache del resolver interno. Questo resolver locale viene poi suggerito ai client collegati al router.

Per sperimentare, dall'interfaccia web posso configurare il router per usare 1.1.1.1, 1.0.0.1, 2606:4700:4700::1111 e 2606:4700:4700::1001 come server DNS upstream (aggiornando gli indirizzi IPv6 se la rete non li supporta):

Screen-Shot-2018-04-09-at-13.15.07

Collegando WAN del router al computer, Wireshark intercetta il traffico in uscita prima della WAN reale. Una richiesta DNS non nella cache viene inoltrata a 1.1.1.1. Poiché il router invia richieste senza crittografia anziché usare DNS-over-TLS, posso vedere queste richieste DNS circolare su Internet in chiaro:

dns_unencrypted

Cloudflare Resolver supporta DNS-over-TLS, ma purtroppo il mio router no e invia tutte le richieste senza crittografia.

Configurazione DNS-Over-TLS

LEDE include Dnsmasq come resolver interno, quindi non supporta DNS-over-TLS. Per crittografare le richieste lo sostituiamo con Unbound e odhcpd. Ho seguito l'utile documentazione del pacchetto Unbound OpenWrt.

Prima di iniziare serve accesso SSH al router. Se viene chiesta la password, probabilmente è quella del portale web:

Screen-Shot-2018-04-09-at-13.06.26

LEDE usa ​opkg​ come gestore pacchetti. Aggiorniamo l'elenco, poi installiamo Unbound, Unbound-Control e la versione completa di odhcpd:

opkg update
opkg install unbound odhcpd unbound-control
opkg remove dnsmasq

Puoi anche installare l'app Luci per Unbound se vuoi controllarlo tramite l'interfaccia utente standard.

opkg install luci-app-unbound

Poiché il router non usa LEDE standard, l'interfaccia non cambierebbe installandolo; non ho provato personalmente questo modulo.

Con Unbound installato, aggiungiamo una configurazione per assicurarci che Unbound usi 1.1.1.1, 1.0.0.1, 2606:4700:4700::1111 e 2606:4700:4700::1001 come resolver DNS con crittografia TLS. Ho aggiunto configurazioni a /etc/unbound/unbound_ext.conf con Vim:

forward-zone:
  name: "."
  forward-addr: 1.1.1.1@853
  forward-addr: 1.0.0.1@853
  forward-addr: 2606:4700:4700::1111@853
  forward-addr: 2606:4700:4700::1001@853
  forward-ssl-upstream: yes

Nel file di configurazione Unbound in /etc/config/unbound, ho aggiunto alcuni parametri richiesti come descritto nella documentazione del pacchetto. Ho salvato il file di configurazione e usato quanto segue:

config unbound
  option add_local_fqdn '1'
  option add_wan_fqdn '1'
  option dhcp_link 'odhcpd'
  option dhcp4_slaac6 '1'
  option domain 'lan'
  option domain_type 'static'
  option listen_port '53'
  option rebind_protection '1'
  option unbound_control '1'

Se nel file sono presenti parametri aggiuntivi, assicurati che nulla sovrascriva quelli impostati, prestando particolare attenzione a unbound_control parametro.

Ho anche unito la configurazione seguente a /etc/config/dhcp (lasciando inalterate alcune voci esistenti):

config dhcp 'lan'
        option dhcpv4 'server'
        option dhcpv6 'server'
        option interface 'lan'
        option leasetime '12h'
        option ra 'server'
        option ra_management '1'

config odhcpd 'odhcpd'
        option maindhcp '1'
        option leasefile '/var/lib/odhcpd/dhcp.leases'
        option leasetrigger '/usr/lib/unbound/odhcpd.sh'

Infine possiamo abilitare l'avvio automatico di Unbound e avviarlo:

service unbound enable
service unbound start

Ecco la prova concreta: intercettando le query DNS tra il router e Internet, vedremo che sono crittografate con TLS v1.2:

dns_unencrypted

Conclusione

In questo articolo abbiamo spiegato come crittografare il traffico DNS possa contribuire a proteggere la privacy durante la navigazione Internet. Sostituendo Dnsmasq con Unbound possiamo consentire a OpenWrt di sfruttare DNS-over-TLS per contribuire a crittografare il traffico web.


Grazie a Junade Ali per averci autorizzato a condividere questo articolo sul nostro sito. L'articolo è stato originariamente pubblicato sul sito Cloudflare il 9 aprile 2018: https://blog.cloudflare.com/dns-over-tls-for-openwrt/

Informazioni su GL.iNet

Fondata nel 2010, GL.iNet è un fornitore leader di router innovativi e soluzioni di rete. Dai router da viaggio compatti ai KVM remoti all'avanguardia, GL.iNet offre tecnologie di rete pluripremiate progettate per garantire prestazioni e sicurezza.

GL.iNet permette a persone e organizzazioni di connettersi con fiducia. Mettendo il controllo nelle mani degli utenti, GL.iNet sostiene la produttività e la collaborazione che contribuiscono a una buona qualità di vita.

Articolo precedente MiFi a energia solare: viaggia in sicurezza rispettando l'ambiente
Articolo successivo GL.iNet debutta al CeBit 2018

Confronta Prodotti

{"one"=>"Seleziona 2 o 3 articoli da confrontare", "other"=>"{{ count }} di 3 elementi selezionati"}

Seleziona il primo elemento da confrontare

Seleziona il secondo elemento da confrontare

Seleziona il terzo elemento da confrontare

Confronta