Poniżej krótkie howto na temat zaszyfrowania zapytań DNS, co pomaga w zabezpieczeniu sieci i uchronieniu jej użytkowników przed przekierowaniem ich na strony niewiadomego pochodzenia, oraz też po części przed inwigilacją i zbieraniem danych na temat tego jakie strony odwiedzają w sieci. Poradnik pisany i testowany w oparciu o OpenWrt Barrier Breaker na routerze TL-WR1043N/ND v2 oraz Archer C7 v2, wersja dnscrypt-proxy to 1.4.0-5.E .
W repo OpenWRT potrzebnych pakietów niestety nie ma -- trzeba korzystać z zewnętrznych repozytoriów. Jednym z nich jest repo dl.eko.one.pl . Jeśli pobieraliśmy dla swojego routera obraz w w/w strony, nie musimy robić nic więcej. Natomiast jeśli korzystaliśmy z obrazów udostępnianych na oficjalnej stronie OpenWRT, musimy dodać poniższą linijkę do pliku /etc/opkg.conf :
src/gz eko1 http://dl.eko.one.pl/barrier_breaker/ar71xx/packages
By zainstalować potrzebne nam oprogramowanie, wydajemy poniższe polecenia:
# opkg update
# opkg install dnscrypt-proxy
dnscrypt-proxy będzie nasłuchiwał zapytań na 127.0.0.1:2053 -- jeśli komuś nie odpowiada adres lub/i port może je zwyczajnie zmienić w pliku /etc/config/dnscrypt-proxy :
...
option address '127.0.0.1'
option port '2053'
...
Dodatkowo, w powyższym pliku znajdują się dwie inne opcje: resolver oraz resolvers_list -- ten drugi to lista prividerów, którzy mają zaimplementowaną obsługę szyfrowania zapytań DNS, natomiast parametr resolver wybiera któregoś z nich. Lista jest dość długa, więc mamy w czym wybierać. Mnie domyślna konfiguracja satysfakcjonuje i nie zmieniam nic w pliku /etc/config/dnscrypt-proxy
.
Teraz musimy przekierować zapytania, w tym celu musimy poinstruować dnsmasq by korzystał z dnscrypt-proxy, a nie domyślnych serwerów DNS pobranych z serwera DHCP od naszego ISP. W pliku /etc/config/dhcp musimy wykomentować wpisy z option resolvfile . Musimy także dopisać kilka nowych linijek, tak by wyglądało to mniej więcej jak poniżej.
# option resolvfile '/tmp/resolv.conf.auto'
option noresolv '1'
list server '127.0.0.1#2053'
list server '/pool.ntp.org/208.67.222.222'
Opcja noresolv sprawi, że dnsmasq nie będzie używał DNSów pobranych z lease DHCP. Trzecia linijka określa gdzie przesyłać zapytania DNS. Ostatni wpis sprawi, że wszelkie zapytania do serwerów czasu będą szły do opendns w formie niezaszyfrowanej. Chodzi generalnie o precyzję pobranego czasu -- by był możliwie dokładny, a operacje, typu szyfrowanie, spowalniają nieco synchronizację czasu. Można tutaj wpisać dowolne DNSy.
Jeśli w tej chwili byśmy zresetowali dnsmasq , w logu (logread) powinniśmy ujrzeć min. poniższe wpisy:
# /etc/init.d/dnsmasq restart
# logread
...
Wed Aug 20 13:33:43 2014 daemon.info dnsmasq[1591]: using nameserver 208.67.222.222#53 for domain pool.ntp.org
Wed Aug 20 13:33:43 2014 daemon.info dnsmasq[1591]: using nameserver 127.0.0.1#2053
...
Jeśli w tej chwili na routerze nie działa odpytywanie domen po nazwach a jedynie po adresach ip, np:
# ping wp.pl
ping: bad address 'wp.pl'
root@red_viper:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=44 time=58.543 ms
64 bytes from 8.8.8.8: seq=1 ttl=44 time=59.077 ms
64 bytes from 8.8.8.8: seq=2 ttl=44 time=59.445 ms
^C
--- 8.8.8.8 ping statistics
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 58.543/59.021/59.445 ms
znaczy, że wszystko jest w porządku i musimy jeszcze wystartować dnscrypt-proxy:
# /etc/init.d/dnscrypt-proxy enable
# /etc/init.d/dnscrypt-proxy start
Sprawdzamy jeszcze raz ping po nazwie:
# ping wp.pl
PING wp.pl (212.77.100.101): 56 data bytes
64 bytes from 212.77.100.101: seq=0 ttl=248 time=17.292 ms
64 bytes from 212.77.100.101: seq=1 ttl=248 time=14.011 ms
64 bytes from 212.77.100.101: seq=2 ttl=248 time=15.858 ms
^C
--- wp.pl ping statistics
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 14.011/15.720/17.292 ms
I już wszystko działa ale tylko na routerze. Musimy jeszcze skonfigurować sieć tak by zapytania z jej hostów również leciały w kanał dnscrypt-proxy. Edytujemy jeszcze raz plik /etc/config/dhcp i w sekcji dla lan dopisujemy:
config dhcp 'lan'
...
list 'dhcp_option' '6,192.168.1.1'
Prawdopodobnie nie trzeba dopisywać powyższej linijki i router uzupełni lease dhcp dla hostów w sieci o wpis DNS ze swoim adresem ip.
Od tej pory wszystkie hosty w naszej sieci, wliczając w to router, będą szyfrować zapytania DNS. Sprawdźmy zatem czy faktycznie te zapytania są szyfrowane. Z dowolnego hosta w sieci, który otrzymuje konfigurację przez DHCP wydajemy poniższe polecenie:
morfik:~$ dig debug.opendns.com txt
; <<>> DiG 9.9.5-4-Debian <<>> debug.opendns.com txt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55507
;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;debug.opendns.com. IN TXT
;; ANSWER SECTION:
debug.opendns.com. 0 IN TXT "server 1.wrw"
debug.opendns.com. 0 IN TXT "flags 20 0 2F6 0"
debug.opendns.com. 0 IN TXT "originid 22970815"
debug.opendns.com. 0 IN TXT "actype 2"
debug.opendns.com. 0 IN TXT "bundle 6114579"
debug.opendns.com. 0 IN TXT "source 77.88.100.90:63983"
debug.opendns.com. 0 IN TXT "dnscrypt enabled (713471645A4D3317)"
;; Query time: 14 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Wed Aug 20 13:52:18 CEST 2014
;; MSG SIZE rcvd: 265
Jeśli widzimy w powyższym logu dnscrypt enabled , znaczy, że wszystko działa jak należy i zapytania DNS są szyfrowane.