Facendo uso del pi-hole, saprete che le vostre richieste effettuate dai vostri client (pc, smartphone, smart tv, etc) vengono inviate ai server DNS configurati (come ad esempio: Cloudflare, Quad9, Opendns etc), ma tutto questo come indicato da diversi utenti nei commenti di questo stesso sito web porta ad alcuni problemi anche gravi:
- Problemi di privacy: Il server dns che hai scelto in fase di installazione e configurazione del pi-hole è veramente sicuro e mantiene realmente le sue promesse di non registrare e usare i dati di navigazione? Ah giusto… non puoi.
- Problemi di hacking: Un utente malintenzionato (un hacker), potrebbe avvelenare un server DNS in modo che l’indirizzo IP di alcuni siti web come le banche, non corrispondano a quello reale, ma bensì otterrete un indirizzo ip fasullo (fake) e quindi verresti re-indirizzato a un sito di phishing. Questo scenario si è già verificato e non è improbabile che accada di nuovo…
Qual’è la soluzione?
Creare un server dns ricorsivo sul nostro raspberry pi o orange pi, o etc. dove è installato il Pi-hole a costo zero, le probabilità che venga attaccato sono veramente ridotte al minimo.
Per farlo quindi cosa installeremo?
Unbound (un software open source, sicuro e sviluppato principalmente da NLnet Labs, VeriSign Inc., Nominet e Kirei), che crea un server DNS ricorsivo. Esso cercherà l’ip del sito web, server, dominio etc. chiedendo direttamente ai server TLD (Top-level domain) in maniera ricorsiva. Nella risoluzione ricorsiva, la risposta avviane tramite name server che abbiano “l’autorità” nel rispondere.
Non mi è ancora chiaro, come si comporta un server dns ricorsivo?
Un servizio DNS ricorsivo come unbound, non è proprietario dei record DNS, e nel nostro caso solo i client (pc, smartphone etc,) che sono collegati al modem/router di casa (in lan o wi-fi), possono effettuare richieste.Unbound è un semplice intermediario da cui è possibile ottenere informazioni. Se il riferimento del sito web che vogliamo visitare è memorizzato nella cache, egli stesso risponderà alla query fornendo l’IP, in caso contrario, inoltrerà la query a uno o più server autorevoli fino a quando recupererà l’informazione richiesta.
Ok, ok! Bel discorso, ma quali svantaggi ci sono?
L’uso di un DNS ricorsivo può essere lento, soprattutto per la prima volta che visiti un sito web, rispetto ai provider DNS che hanno sempre le risposte per i domini di uso comune nella loro cache. La prima richiesta a un TLD precedentemente sconosciuto può richiedere fino a un secondo (o anche di più se utilizzi anche DNSSEC). Le richieste successive ai domini sotto lo stesso TLD di solito vengono completate in <0,1 secondi. Fortunatamente, sia il tuo Pi-hole che il tuo server ricorsivo possiedono una cache efficiente per memorizzare i dati necessari, e questo riduce al minimo il numero di query che dovranno essere effettivamente eseguite.
Installazione di unbound
AVVISO: Devo ovviamente segnalarvi per motivi legali (non si sà mai che qualcuno mi denunci per danni) che non sono assolutamente responsabile di qualsiasi danno e/o problema hardware e/o software causato al vostro sistema (qualsiasi esso sia, solo come esempio: raspberry/server/pc/etc.).
Faccio presente che l’installazione del software presente è stato testato personalmente, ed è anche in funzione sul mio raspberry, ma è sempre possibile incorrere in problemi.
Prima di installare il pacchetto di unbound, DOVETE effettuare questi comandi i quali sono realmente necessari per non incorrere in problemi durante l’installazione (cosa che a me è accaduta perché non avevo il sistema aggiornato, ed è stato un vero delirio uscirne):
sudo apt update |
e poi:
sudo apt full-upgrade -y |
Una volta che il vostro sistema operativo (come ad esempio raspbianOS per il raspberry) sarà aggiornato, possiamo procedere all’installazione del software effettuando il seguente comando:
sudo apt install unbound |
come nello screenshot seguente:
Potresti come nel mio caso, incorrere in alcuni errori (anche se hai effettuato update del sistema), non ti preoccupare, saranno risolti continuando a seguire questa guida/procedura (effettuando i relativi comandi segnalati).
Con questo comando verrà installato e compilato il file root.hints, questo file conterrà una lista dei server root primari, necessari per inizializzare la cache dei server dei nomi di dominio su Internet:
wget https://www.internic.net/domain/named.root -qO- | sudo tee /var/lib/unbound/root.hints |
come nello screenshot seguente:
Ora è necessario impostare e creare il file di log per unbound, questo ci potrà tornare utile in caso di debug cioè, in caso di problemi, sarà possibile analizzare il file di log per capire cosa sia andato storto:
sudo mkdir -p /var/log/unbound sudo touch /var/log/unbound/unbound.log sudo chown unbound /var/log/unbound/unbound.log |
Creare e impostare il file usr.sbin.unbound eseguendo il comando:
sudo nano /etc/apparmor.d/local/usr.sbin.unbound |
e copiare il seguente testo
/var/log/unbound/unbound.log rw, |
Salvare e uscire (premere i tasti Ctrl X e poi S per confermare).
Adesso è fondamentale creare e impostare il file di configurazione pi-hole.conf eseguendo il comando:
sudo nano /etc/unbound/unbound.conf.d/pi-hole.conf |
Qui sarà essenziale copiare e incollare il seguente testo:
server:
# If no logfile is specified, syslog is used
logfile: "/var/log/unbound/unbound.log"
verbosity: 1
interface: 127.0.0.1
port: 5335
do-ip4: yes
do-udp: yes
do-tcp: yes
# May be set to yes if you have IPv6 connectivity
do-ip6: no
# You want to leave this to no unless you have *native* IPv6. With 6to4 and
# Terredo tunnels your web browser should favor IPv4 for the same reasons
prefer-ip6: no
# Use this only when you downloaded the list of primary root servers!
# If you use the default dns-root-data package, unbound will find it automatically
root-hints: "/var/lib/unbound/root.hints"
# Trust glue only if it is within the server's authority
harden-glue: yes
# Require DNSSEC data for trust-anchored zones, if such data is absent, the zone becomes BOGUS
harden-dnssec-stripped: yes
# Don't use Capitalization randomization as it known to cause DNSSEC issues sometimes
# see https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378 for further details
use-caps-for-id: no
# Reduce EDNS reassembly buffer size.
# IP fragmentation is unreliable on the Internet today, and can cause
# transmission failures when large DNS messages are sent via UDP. Even
# when fragmentation does work, it may not be secure; it is theoretically
# possible to spoof parts of a fragmented DNS message, without easy
# detection at the receiving end. Recently, there was an excellent study
# >>> Defragmenting DNS - Determining the optimal maximum UDP response size for DNS <<<
# by Axel Koolhaas, and Tjeerd Slokker (https://indico.dns-oarc.net/event/36/contributions/776/)
# in collaboration with NLnet Labs explored DNS using real world data from the
# the RIPE Atlas probes and the researchers suggested different values for
# IPv4 and IPv6 and in different scenarios. They advise that servers should
# be configured to limit DNS messages sent over UDP to a size that will not
# trigger fragmentation on typical network links. DNS servers can switch
# from UDP to TCP when a DNS response is too big to fit in this limited
# buffer size. This value has also been suggested in DNS Flag Day 2020.
edns-buffer-size: 1232
# Perform prefetching of close to expired message cache entries
# This only applies to domains that have been frequently queried
prefetch: yes
# One thread should be sufficient, can be increased on beefy machines. In reality for most users running on small networks or on a single machine, it should be unnecessary to seek performance enhancement by increasing num-threads above 1.
num-threads: 1
# Ensure kernel buffer is large enough to not lose messages in traffic spikes
so-rcvbuf: 1m
# Ensure privacy of local IP ranges
private-address: 192.168.0.0/16
private-address: 169.254.0.0/16
private-address: 172.16.0.0/12
private-address: 10.0.0.0/8
private-address: fd00::/8
private-address: fe80::/10
Salvare e uscire (premere i tasti Ctrl X e poi S per confermare).
Si segnala che il testo segnalato rappresenta la configurazione standard, è possibile effettuare alcune modifiche in base alle proprie esigenze (come ad esempio aumentare la cache, etc.), non inserire o modificare o aggiungere, parametri copiandoli da altri siti, se non capite cosa state facendo, in quanto potreste creare seri problemi di connessione, quindi vi prego leggete la relativa manualistica (come ad esempio: https://unbound.docs.nlnetlabs.nl/en/latest/ ).
Ora è indispensabile modificare il file presente nel percorso /etc/dnsmasq.d/99-edns.conf , quindi effettueremo il comando:
sudo nano /etc/dnsmasq.d/99-edns.conf |
e copiare al suo interno il seguente testo:
edns-packet-max=1232 |
Salvare e uscire (premere i tasti Ctrl X e poi S per confermare).
Questa modifica eviterà un errore sul pihole con la seguente dicitura d’esempio: Warning in dnsmasq core: reducing DNS packet.
Se possedete come sistema operativo raspbian Os (su raspberry pi) oppure Debian e suoi derivati (con la versione Bullseye+ o superiore) è obbligatorio disattivare il servizio resolvconf (esso risulta integrato nel pacchetto d’installazione e/o aggiornamento), il quale può causare dei problemi, per farlo eseguire i seguenti comandi:
systemctl is-active unbound-resolvconf.service sudo systemctl disable --now unbound-resolvconf.service sudo sed -Ei 's/^unbound_conf=/#unbound_conf=/' /etc/resolvconf.conf sudo rm /etc/unbound/unbound.conf.d/resolvconf_resolvers.conf |
Effettuiamo un restart del servizio unbound, questo farà in modo che vengano implementate tutte le modifiche che abbiamo effettuato:
sudo service unbound restart |
Ora è tempo di verificare che il servizio sia effettivamente attivo e funzionante con il seguente comando:
sudo service unbound status |
L’output deve indicarci che lo stato è active (running) ed è di colore verde, in pratica come questo:
Se non è in stato active è necessario effettuare delle verifiche sul sistema, inserite tranquillamente il vostro commento su questa guida, cercherò di aiutarvi come posso, inoltre è importante segnalare che non si stà effettuando nessun disservizio, il vostro pihole non è stato ancora configurato completamente per usare unbound (sta ancora funzionando alla vecchia maniera).
Effettuiamo quindi un primo test di funzionamento (si segnala che la configurazione non è ancora terminata).
dig pi-hole.net @127.0.0.1 -p 5335 |
La prima query impiegherà un po di tempo, ma non allarmatevi è del tutto normale.
Nell’output del comando dovete verificare che sulla voce “status:” ci sia il valore: NOERROR. Qui potete anche verificare il tempo in ms, nel campo “Query time”:
Solo se riscontrare l’errore SERVFAIL, provate ad effettuate anche un altro comando dig edicolac64.com @127.0.0.1 -p 5335
se continuate a ricevere lo stesso messaggio, è necessario effettuare delle verifiche sul sistema, inserite tranquillamente il vostro commento su questa guida, cercherò di aiutarvi come posso.
E’ tutto ok? Allora ri-effettuare lo stesso comamndo, fino a che il campo Query Time non sia a 0, questo ci serve per capire che anche la cache di unbound (impostata di default dal software) sia correttamente funzionante.
Configurare Pihole per Unbound
Rechiamoci sulla pagina amministrativa del nostro pihole, dal menu scegliere la voce Setting e quindi poi nella finestra la voce DNS, qui sarà necessario eliminare qualsiasi tipo di visto sulla parte Upstream DNS server e in Custom (IPv4) inserire il seguente testo:
127.0.0.1#5335 |
In pratica dovete avere una situazione identica allo screenshot seguente:
Clicchiamo sul tasto Save, in basso a destra, abbiamo terminato.
Nota finale: Ci sono molte discussioni in giro sul fatto che sia necessario disabilitare il DNSSEC sul pihole (se abilitato nella schermata precedente), visto che si sta usando unbound, la verità è che in passato esisteva un bug che poteva creare problemi ma è stato risolto; io ho effettuato dei test senza riscontrare effettivamente dei rallentamenti sui tempi di risposta in ms quindi ho lascio attiva tale opzione, fate anche voi dei test e lascio quindi a voi la scelta di tenerlo abilitato o meno.
Ciao Giovanni,interessante questa guida,io se ricordi grazie alla tua disponibilità ho installato Dnscrypt sul raspberry os posso lasciare l’attuale configurazione o mi consigli di usare unbound? Buona Domenica.
Per una maggiore sicurezza ti consiglio di usare unbound, d’altronde anche io ho attivato tale sw.
Grazie Giovanni
Ciao io arrivo ad un certo punto dell’installazione e ricevo l’errore:
pi@Pi-Hole:~ $ sudo systemctl disable –now unbound-resolvconf.service
Invalid unit name “–now” escaped as “\xe2\x80\x93now” (maybe you should use systemd-escape?).
Failed to disable unit: Unit file \xe2\x80\x93now.service does not exist.
pi@Pi-Hole:~ $ sudo sed -Ei ‘s/^unbound_conf=/#unbound_conf=/’ /etc/resolvconf.conf
sed: espressione -e #1, carattere 1: comando sconosciuto: `?’
pi@Pi-Hole:~ $
ciao, ho effettuato una correzione alla guida, il testo non era caratterizzato come codice di programmazione, i comandi da eseguire sono questi:
sudo systemctl disable --now unbound-resolvconf.service
sudo sed -Ei 's/^unbound_conf=/#unbound_conf=/' /etc/resolvconf.conf
Fammi sapere se riscontri ancora anomalie.
ora si presenta questa situazione
sudo service unbound restart
Job for unbound.service failed because the control process exited with error code.
See “systemctl status unbound.service” and “journalctl -xe” for details.
Fai questi comandi
sudo nano /etc/apparmor.d/local/usr.sbin.unbound
e copiare il seguente testo
/var/log/unbound/unbound.log rw,
Salva e esci (tasti ctrl+x e poi S)
Rifai il comando
sudo nano /etc/unbound/unbound.conf.d/pi-hole.conf
cancella tutto il testo all’interno e copia il testo corretto (server: …) che è stato fixato e trovi nella guida sopra (ho notato che prima non prendeva gli spazi, ora con una modifica al codice della pagina ho risolto) e rifai il comando
sudo service unbound restart
ora non dovresti avere errori e puoi continuare da dove eri rimasto.
perfetto adesso è andato tutto ok
Ottimo, felice di essere stato d’aiuto, se puoi e vuoi, ricorda di effettuare una donazione è sempre ben accetta.
Ciao, nel mio caso Pihole è su docker, mi consigli d’installare Unbound in un altro contenitore, o nello stesso di Pihole?
Ciao, installalo sullo stesso del pihole
Ho iniziato la confiugurazione , ma quando arrivo a lanciare “sudo service unbound restart” ottengo “s6 service not found for unbound, exiting…”
Ho cercato su Google e sembra che unbound non possa essere instlato nello stesso contenitore di pihole. Ti risulta?
Grazie 🙂
Ciao, io avevo eseguito una guida su github, purtroppo ora non riesco a trovarla e quelle che ho trovato sono vecchie e non sò se andrebbero bene, visto le modifiche e gli aggiornamenti dei due software. A questo punto, per andare sul sicuro e non riscontrare problemi, ti consiglio di seguire questa che fà uso di container diversi: https://github.com/patrickfav/pihole-unbound-docker