Unbound DNSSEC через DNSCrypt

dnssec-logo Установка Unbound в качестве DNSSEC-клиента в ОС Debian-based с переадресацией ДНС-запросов через DNSCrypt для защиты от подмены ДНС адреса сводится к выполнению всего нескольких простых шагов: собственно сама установка и последующая правка resolv.conf.

Сей пост посвященный криптографической защите DNS-трафика по сути является продолжением темы "паранойи много не бывает". Кругом враги и глобальные заговоры злых соседей, государства и транснациональных корпораций. Кто-то скажет пора лечится и я полностью соглашусь, но некогда имхо врагов который год всё не убывает, а значит нужно усиливать меры безопасности, ведь они идут, они заполоняют...

Итак... DNSSEC (ака Domain Name System Security Extensions) — это набор расширений безопасности системы доменных имён (протокола DNS), которые позволяют обеспечить целостность DNS-запросов между клиентом и сервером с использованием криптографии с открытым ключом.

Зачем нужен DNSSEC?

Служба доменных имен (DNS) нужна для того, чтобы облегчить пользователям запоминание адресов веб-ресурсов, ведь проще запомнить имя сайта чем его цифровой ИП-адрес. Далеко не каждому пользователю Интернетоф известно, что одному доменному имени может быть присвоено несколько ИП-адресов, что обеспечивает отказоустойчивость веб-ресурсам, для которых 100% аптайм является критически важным критерием, примером может быть ПС yandex.ru:

$ nslookup yandex.ru
Server:     127.0.0.1
Address:    127.0.0.1#53
 
Non-authoritative answer:
Name:   yandex.ru
Address: 5.255.255.55
Name:   yandex.ru
Address: 77.88.55.66
Name:   yandex.ru
Address: 5.255.255.5
Name:   yandex.ru
Address: 77.88.55.55

Выше приведён список валидных ИП-адресов для ПС yandex.ru. Теперь предположим, что на нашем канале связи висит туева хуча спец. служб, которая хочет закинуть нашей машине различного "пакращення", и мы значит вбиваем в строку своего браузера доменное имя yandex.ru, а злые люди подменяют приведённый выше список ИП на ИП своего бацыльного сервера на котором висит фейковая поисковая система с элементами социальной инженерии, клюнув на которую мы широко развесив ухи "сдаем" все свои явки и пароли дополнительно получая при этом кучу всяких доселе ещё никому неизвестных вирусов и троянов, - поздравляю вам пи.дец :)

Вот именно для защиты от подмены этих самых ИП-адресов, подмена которых чревата упомянутыми выше лулзами, и призван DNSSEC.

Установка Unbound в Debian-based ОС

Мы не доверяем нашему ISP и потому просто выполняем:

apt-get install unbound unbound-anchor

Проверяем состояние сервиса unbound:

# systemctl status unbound -l
● unbound.service - (null)
   Loaded: loaded (/etc/init.d/unbound)
  Drop-In: /run/systemd/generator/unbound.service.d
           └─50-insserv.conf-$named.conf, 50-unbound-$named.conf
   Active: active (running) since Чт 2015-10-29 08:45:16 EET; 57s ago
   CGroup: /system.slice/unbound.service
           └─28210 /usr/sbin/unbound
 
окт 29 08:45:15 falian unbound-anchor[28207]: /var/lib/unbound/root.key has content
окт 29 08:45:15 falian unbound-anchor[28207]: success: the anchor is ok
окт 29 08:45:16 falian unbound[28210]: [28210:0] notice: init module 0: validator
окт 29 08:45:16 falian unbound[28210]: [28210:0] notice: init module 1: iterator
окт 29 08:45:16 falian unbound[28210]: [28210:0] info: start of service (unbound 1.4.22).
окт 29 08:45:16 falian unbound[28200]: Starting recursive DNS server: unbound.

Правим resolv.conf:

vi /etc/resolv.conf
or
vi /etc/resolvconf/resolv.conf.d/head
#nameserver 8.26.56.26
#nameserver 8.20.247.20
#nameserver 8.8.8.8
#nameserver 8.8.4.4
nameserver 127.0.0.1
 
resolvconf -u

Проверяем DNSSEC по наличию флага "ad" и записи "RRSIG" в результате выполнения dig com. SOA +dnssec:

$ dig com. SOA +dnssec
 
; <<>> DiG 9.9.5-9+deb8u3-Debian <<>> com. SOA +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17068
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 14, ADDITIONAL: 1
 
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;com.               IN  SOA
 
;; ANSWER SECTION:
com.            577 IN  SOA a.gtld-servers.net. nstld.verisign-grs.com. 1446101237 1800 900 604800 86400
com.            577 IN  RRSIG   SOA 8 1 900 20151105074717 20151029053717 51797 com. oo4o1US7CPYmkmSYoEqC0wPN2vFpxXJTgUn/MIBvP4PiRS64ZjCLNLtr Vd35ebK07XvqYJMVWSvSyL7pK7b3jqiOmwBKCT1K7+HVLS362H4mwvjS JFW9C6+eC4FHxPSnOpxuIfDshgc5lhGHHq7pCbeOVxHrUgrAP7a7bZyV cX4=
 
;; AUTHORITY SECTION:
com.            161505  IN  NS  d.gtld-servers.net.
com.            161505  IN  NS  b.gtld-servers.net.
com.            161505  IN  NS  k.gtld-servers.net.
com.            161505  IN  NS  f.gtld-servers.net.
com.            161505  IN  NS  a.gtld-servers.net.
com.            161505  IN  NS  h.gtld-servers.net.
com.            161505  IN  NS  i.gtld-servers.net.
com.            161505  IN  NS  c.gtld-servers.net.
com.            161505  IN  NS  m.gtld-servers.net.
com.            161505  IN  NS  e.gtld-servers.net.
com.            161505  IN  NS  l.gtld-servers.net.
com.            161505  IN  NS  j.gtld-servers.net.
com.            161505  IN  NS  g.gtld-servers.net.
com.            161505  IN  RRSIG   NS 8 1 172800 20151104055508 20151028034508 51797 com. DXj9YJiiWPCKHnY69NnAj4gzbP9FpY1gpW+JfQHU5gdT2UEXz0JcJpCE VoMs3VyzHmb+j4QNZmk+PbGwyBl8LAVZ4UQFrV899IKQjIYaOeUdPJQe 9FV805QOvZQ7uk3f6xlpTzkvHHFqf1OzbMka6Ho+ILG415Z0n9Fj5W71 N5U=
 
;; Query time: 194 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Oct 29 08:52:46 EET 2015
;; MSG SIZE  rcvd: 637

Конфигурационные файлы unbound:

/etc/default/unbound
/etc/unbound/unbound.conf
/etc/unbound/unbound.conf.d/
/etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conf
 
---
 
less /etc/unbound/unbound.conf
 
# Unbound configuration file for Debian.
#
# See the unbound.conf(5) man page.
#
# See /usr/share/doc/unbound/examples/unbound.conf for a commented
# reference config file.
#
# The following line includes additional configuration files from the
# /etc/unbound/unbound.conf.d directory.
include: "/etc/unbound/unbound.conf.d/*.conf"
 
---
 
less /etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conf
 
server:
    # The following line will configure unbound to perform cryptographic
    # DNSSEC validation using the root trust anchor.
    auto-trust-anchor-file: "/var/lib/unbound/root.key"

Владельцем ключа "/var/lib/unbound/root.key" является пользователь "unbound", от имени которого также работает и сам сервис unbound.

Ключ "/var/lib/unbound/root.key" должен регулярно обновляться, что с успехом автоматически выполняет скрипт управления демоном "/etc/init.d/unbound" в момент старта/запуска/перезапуска и никаких дополнительных манипуляций не требует.

Настройка Unbound в Debian-based ОС

Кого устраивает конфигурация по умолчанию, умолчания смотрите в файле /usr/share/doc/unbound/examples/unbound.conf, то можно пропустить сей конфиг. Нам лично умолчания не подходят и потому конфиг /etc/unbound/unbound.conf мы допиливаем до такой кондиции:

vi /etc/unbound/unbound.conf
 
## Authoritative, validating, recursive caching DNS
# See /usr/share/doc/unbound/examples/unbound.conf for a commented
# reference config file.
## unbound.conf -- http://www.remoteshaman.com
#
server:
 
    # File with trusted keys, kept uptodate using RFC5011 probes,
    # initial file like trust-anchor-file, then it stores metadata.
    # Use several entries, one per domain name, to track multiple zones.
    #
    # If you want to perform DNSSEC validation, run unbound-anchor before
    # you start unbound (i.e. in the system boot scripts).  And enable:
    # Please note usage of unbound-anchor root anchor is at your own risk
    # and under the terms of our LICENSE (see that file in the source).
    #
    # The following line will configure unbound to perform cryptographic
    # DNSSEC validation using the root trust anchor.
    auto-trust-anchor-file: "/var/lib/unbound/root.key"
 
    interface: 0.0.0.0
    interface: ::0
 
    # port to answer queries from
    port: 53
 
    # Enable IPv4, "yes" or "no".
    do-ip4: yes
 
    # Enable IPv6, "yes" or "no".
    do-ip6: no
 
    # Enable UDP, "yes" or "no".
    do-udp: yes
 
    # Enable TCP, "yes" or "no". If TCP is not needed, Unbound is actually
    # quicker to resolve as the functions related to TCP checks are not done.i
    # NOTE: you may need tcp enabled to get the DNSSEC results from *.edu domains
    # due to their size.
    do-tcp: yes
 
    # control which clients are allowed to make (recursive) queries
    # to this server. Specify classless netblocks with /size and action.
    # By default everything is refused, except for localhost.
    # Choose deny (drop message), refuse (polite error reply),
    # allow (recursive ok), allow_snoop (recursive and nonrecursive ok)
    # deny_non_local (drop queries unless can be answered from local-data)
    # refuse_non_local (like deny_non_local but polite error reply).
    #access-control: 0.0.0.0/0 refuse
    #access-control: ::0/0 refuse
    #access-control: 127.0.0.0/8 allow
    #access-control: ::1 allow
    #access-control: ::ffff:127.0.0.1 allow
    #access-control: 10.0.0.0/16 allow
    #access-control: 192.168.0.0/16 allow
    #access-control: 192.168.0.0/16 allow
 
    # enable remote-control
    #remote-control:
        #control-enable: yes
 
    # enable to not answer id.server and hostname.bind queries.
    hide-identity: yes
 
    # enable to not answer version.server and version.bind queries.
    hide-version: yes
 
    # Will trust glue only if it is within the servers authority.
    # Harden against out of zone rrsets, to avoid spoofing attempts. 
    # Hardening queries multiple name servers for the same data to make
    # spoofing significantly harder and does not mandate dnssec.
    harden-glue: yes
 
 
    # the time to live (TTL) value lower bound, in seconds. Default 0.
    # If more than an hour could easily give trouble due to stale data.
    cache-min-ttl: 3600
 
    # the time to live (TTL) value cap for RRsets and messages in the
    # cache. Items are not cached for longer. In seconds.
    cache-max-ttl: 86400
 
    # perform prefetching of close to expired message cache entries.  
    # If a client requests the dns lookup and the TTL of the cached hostname 
    # is going to expire in less than 10% of its TTL, unbound will (1st) 
    # return the ip of the host to the client and (2nd) pre-fetch the dns 
    # request from the remote dns server. This method has been shown to 
    # increase the amount of cached hits by local clients by 10% on average.
    prefetch: yes
 
    # number of threads to create. 1 disables threading. 
    # This should equal the number of CPU cores in the machine.
    num-threads: 1
 
    # the amount of memory to use for the RRset cache.
    # plain value in bytes or you can append k, m or G. default is "4Mb". 
    #rrset-cache-size: 4m
 
    # the amount of memory to use for the message cache.
    # plain value in bytes or you can append k, m or G. default is "4Mb". 
    #msg-cache-size: 4m
 
    # Uncoment if you wish use Unbound through dnscrypt-proxy
    # http://dnscrypt.org/#dnscrypt-proxy
    #do-not-query-localhost: no
 
    # Use the following forward-zone to forward all queries to Google DNS,
    # OpenDNS.com or your local ISP's dns servers for example.
    # To test resolution speeds use "drill calomel.org @8.8.8.8" 
    # and look for the "Query time:" in milliseconds.
    #
    forward-zone:
        name: "."
        forward-addr: 8.26.56.26        # Comodo DNS
        forward-addr: 8.20.247.20       # Comodo DNS
        forward-addr: 8.8.8.8           # Google Public DNS
        forward-addr: 8.8.4.4           # Google Public DNS
        #forward-addr: 74.82.42.42      # Hurricane Electric
        #forward-addr: 4.2.2.4          # Level3 Verizon
        #
        # Uncoment if you wish use Unbound through dnscrypt-proxy
        # http://dnscrypt.org/#dnscrypt-proxy
        #forward-addr: 127.0.0.1@40      # dnscrypt-proxy
        #forward-addr: 127.0.0.1@41      # dnscrypt-proxy
#
#
## Authoritative, validating, recursive caching DNS
## unbound.conf -- http://www.remoteshaman.com

Защитим файл конфигурации от изменений: chattr +i /etc/unbound/unbound.conf

good-mem Проходим тест здесь или здесь или установим плагин DNSSEC Validator для браузера Firefox. DNSSEC Validator для браузера Firefox использует DANE протокол.

Вот и всё, теперь мы как минимум на 90-98% защищены от подмены ДНС адреса, но только при условии если на ДНС сервере, на котором размещён домен имеется расширение DNSSEC и домен подписан.

Например, если мы запросим данные о домене dnssectest.sidnlabs.nl, на котором мы проверяли наш ДНС-ресолвер, то увидим запись с подписью (ака RRSIG):

$ dig dnssectest.sidnlabs.nl. SOA +dnssec
 
; <<>> DiG 9.9.5-9+deb8u3-Debian <<>> dnssectest.sidnlabs.nl. SOA +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1529
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 1
 
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;dnssectest.sidnlabs.nl.        IN  SOA
 
;; ANSWER SECTION:
dnssectest.sidnlabs.nl. 3280    IN  CNAME   check.sidnlabs.nl.
dnssectest.sidnlabs.nl. 3280    IN  RRSIG   CNAME 8 3 3600 20151115063544 20151016061750 20853 sidnlabs.nl. rugYHypBs7h+StBzVOmbilncuCdGWwSCVw5SuIT+X+hVeYuWqDwr01Qq bVtdXvrKVJqr1+ehgG8zoGW2Oap9YH2mVR32sgIdQ7o2vHV5j8r6nNY3 PgxRC3B9hx2IUe2iTrVuhfeE6StUZtG03MTL9jR12ePnNXCF3m6AlPeA zXs=
 
;; AUTHORITY SECTION:
sidnlabs.nl.        3600    IN  SOA proteus.sidnlabs.nl. hostmaster.sidn.nl. 1032 14400 3600 604800 300
sidnlabs.nl.        3600    IN  RRSIG   SOA 8 2 3600 20151129172753 20151030162753 20853 sidnlabs.nl. uPqqbk3Rrq4KLTYu4sLVMq65SAMYT8yDO+r18znoenY4aEf7ys+zcmlg ZYLpS0phtCrT4tTQPAR2fP2xTU+9xtY0lHou222lavvKjDqxPW9oI/lR 3ntvSiLupYj+mQniM3cJGwuWLgeoj5IgUEkOjBb9jWu0sI9xFUFsr4RJ QDg=
check.sidnlabs.nl.  3600    IN  NSEC    _443._tcp.check.sidnlabs.nl. A AAAA LOC RRSIG NSEC
check.sidnlabs.nl.  3600    IN  RRSIG   NSEC 8 3 300 20151127045551 20151028044515 20853 sidnlabs.nl. k0L4RnGaZG5Lnvi9EEtVKOXhTgmxDV+FIg1vt30F8FEdanLOxFkZocvo B00Us441fDPBJly4uN+CRM9+tkykTTjL+ZaBh7x6Kaeb/9+aByAqU/xZ yshEALGew3jPZGfOC+5F3eREP1RdOT14XLdyR8Gvvli3BPhuYu+X2PYf vb8=
 
;; Query time: 90 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Oct 31 03:21:47 EET 2015
;; MSG SIZE  rcvd: 693

Но запросив данные о google.com этой подписи мы не обнаружим, а следовательно надеяться на целостность ДНС-запроса мы не можем:

$ dig google.com. SOA +dnssec
 
; <<>> DiG 9.9.5-9+deb8u3-Debian <<>> google.com. SOA +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23487
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 5
 
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;google.com.            IN  SOA
 
;; ANSWER SECTION:
google.com.     3281    IN  SOA ns1.google.com. dns-admin.google.com. 106735125 900 900 1800 60
 
;; AUTHORITY SECTION:
google.com.     345281  IN  NS  ns1.google.com.
google.com.     345281  IN  NS  ns3.google.com.
google.com.     345281  IN  NS  ns2.google.com.
google.com.     345281  IN  NS  ns4.google.com.
 
;; ADDITIONAL SECTION:
ns1.google.com.     254394  IN  A   216.239.32.10
ns3.google.com.     262611  IN  A   216.239.36.10
ns2.google.com.     254693  IN  A   216.239.34.10
ns4.google.com.     292135  IN  A   216.239.38.10
 
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Oct 31 03:26:16 EET 2015
;; MSG SIZE  rcvd: 221

Из приведённого выше слудет, что DNSSEC является хорошим способом обеспечения безопасности и шифрования ДНС-запросов. Для запуска DNSSEC в глобальном масштабе, необходимо подписать корневые зоны (.com .org etc), что было сделано уже в 2010 году, SU была подписана в октябре 2011 года, зоны РФ и RU в конце 2012 года. Дальнейшее же продвижение DNSSEC зависит от компаний, обслуживающих авторитарные DNS сервера в своих зонах - регистраторов и хостеров. Однако, в силу того, что до сих пор ещё не на всех ДНС серверах используется DNSSEC, надеяться на шифрование всех ДНС-запросов без исключения не приходится ибо ДНС-провайдеры плевать хотели на DNSSEC. Поддержку DNSSEC на своих кеширующих DNS серверах также должны реализовать и Интернет-провайдеры.

Параноикам же экстра класса пока необойтись без полной криптографической защиты DNS-трафика с поддержкой DNSSEC включительно, которую можно заполучить с помощью DNSCrypt.

Установка DNSCrypt в Debian-based ОС

На странице "DNSCrypt - Official Project Home Page" сказано, что для большинства модерновых/современных Linux/BSD систем существуют готовые установочные пакеты, а для иных систем предлагается компиляция dnscrypt-proxy source code и единственной зависимостью для компиляции требуется библиотека libsodium.

В Debian Jessie пакет dnscrypt-proxy отсутствует, однако есть dnscrypt-proxy в SID. Библиотека libsodium есть для Debian Jessie, поэтому из репозитория установим только libsodium, а dnscrypt-proxy скомпилируем самостоятельно:

# apt-get install libsodium13
# ldconfig
 
# cd /opt
# wget http://download.dnscrypt.org/dnscrypt-proxy/dnscrypt-proxy-1.6.0.tar.gz
# tar -zxf dnscrypt-proxy-*.tar.gz && rm -rf dnscrypt-proxy-*.tar.gz
# cd dnscrypt-proxy-*
 
# ./autogen.sh
...
Cant exec "libtoolize": Нет такого файла или каталога at /usr/share/autoconf/Autom4te/FileUtils.pm line 345, <GEN7> line 5.
autoreconf: failed to run libtoolize: Нет такого файла или каталога
autoreconf: libtoolize is needed because this package uses Libtool
 
# apt-get install build-essential libtool
# ./autogen.sh
# ./configure --help
# ./configure --prefix=/opt/dnscrypt
...
configure: error: libsodium >= 0.7.0 not found
 
# ln -s /usr/lib/i386-linux-gnu/libsodium.so.13 /usr/lib/i386-linux-gnu/libsodium.so
 
# ./configure --prefix=/opt/dnscrypt
# make
...
make[4]: вход в каталог «/opt/dnscrypt-proxy-1.6.0/src/proxy»
gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../..  -I../ext -I../libevent-modified/include -DPKGDATADIR='"/opt/dnscrypt/share/dnscrypt-proxy"'  -D_FORTIFY_SOURCE=2 -I/usr/local/include  -g -O2 -fPIC -fPIE -fno-strict-aliasing -fno-strict-overflow -fstack-protector-all -Winit-self -Wwrite-strings -Wdiv-by-zero -MT dnscrypt_proxy-app.o -MD -MP -MF .deps/dnscrypt_proxy-app.Tpo -c -o dnscrypt_proxy-app.o `test -f 'app.c' || echo './'`app.c
app.c:19:20: fatal error: sodium.h: Нет такого файла или каталога
 #include <sodium.h>
                    ^
compilation terminated.
Makefile:530: ошибка выполнения рецепта для цели «dnscrypt_proxy-app.o»
make[4]: *** [dnscrypt_proxy-app.o] Ошибка 1
make[4]: выход из каталога «/opt/dnscrypt-proxy-1.6.0/src/proxy»
Makefile:392: ошибка выполнения рецепта для цели «all»
make[3]: *** [all] Ошибка 2
make[3]: выход из каталога «/opt/dnscrypt-proxy-1.6.0/src/proxy»
Makefile:377: ошибка выполнения рецепта для цели «all-recursive»
make[2]: *** [all-recursive] Ошибка 1
make[2]: выход из каталога «/opt/dnscrypt-proxy-1.6.0/src»
Makefile:507: ошибка выполнения рецепта для цели «all-recursive»
make[1]: *** [all-recursive] Ошибка 1
make[1]: выход из каталога «/opt/dnscrypt-proxy-1.6.0»
Makefile:413: ошибка выполнения рецепта для цели «all»
make: *** [all] Ошибка 2
 
# apt-get install libsodium-dev
# make install

Бинарные файлы будут установлены сюда

/opt/dnscrypt/bin/hostip
/opt/dnscrypt/sbin/dnscrypt-proxy
 
man /opt/dnscrypt/share/man/man8/dnscrypt-proxy.8
man /opt/dnscrypt/share/man/man8/hostip.8

Есть важное замечание! Если Unbound работает с проверкой DNSSEC в комбинации с сервером не поддерживающими DNSSEC, тогда все запросы будут неудачными. В таком случае нужно DNSCrypt resolvers которые поддерживают DNSSEC или же отключить DNSSEC в Unbound поставив символ комментария перед auto-trust-anchor-file.

Файл со списком публичных dnscrypt-резолверов поддерживающих DNSSEC можно найти в каталоге с исходным кодом less dnscrypt-resolvers.csv или же по ссылке list of public DNS resolvers, или просто выберите один из этого списка:

  • cloudns-can - CloudNS Canberra, CloudNS is an Australian based security focused DNS provider.
  • cloudns-syd - CloudNS Sydney, CloudNS is an Australian based security focused DNS provider.
  • dnscrypt.eu-dk - DNSCrypt.eu Denmark, "Free, non-logged, uncensored. Hosted by Netgroup."
  • dnscrypt.eu-dk-ipv6 - DNSCrypt.eu Denmark over IPv6, "Free, non-logged, uncensored. Hosted by Netgroup."
  • dnscrypt.eu-dk-port5353 - DNSCrypt.eu Denmark (port 5353), "Free, non-logged, uncensored. Hosted by Netgroup."
  • dnscrypt.eu-nl - DNSCrypt.eu Holland, "Free, non-logged, uncensored. Hosted by RamNode.", Netherlands
  • dnscrypt.eu-nl-ipv6 - DNSCrypt.eu Holland over IPv6, "Free, non-logged, uncensored. Hosted by RamNode.", Netherlands
  • dnscrypt.eu-nl-port5353 - DNSCrypt.eu Holland (port 5353), "Free, non-logged, uncensored. Hosted by RamNode.", Netherlands
  • dnscrypt.org-fr - "DNSCrypt server in France", "DNSSEC/Namecoin/Non-logged/Uncensored - ARM server donated by Scaleway.com"
  • soltysiak - Soltysiak, Public DNSCrypt server in Poland,Poland

Теперь осталось подпилить конфигурацию Unbound и запустить dnscrypt-proxy, добавить в /etc/rc.local для автозапуска и перезапустить Unbound:

# vi /etc/unbound/unbound.conf
 
## Authoritative, validating, recursive caching DNS
# See /usr/share/doc/unbound/examples/unbound.conf for a commented
# reference config file.
## unbound.conf -- http://www.remoteshaman.com
#
server:
 
    # ...
 
    # Uncoment if you wish use Unbound through dnscrypt-proxy
    # http://dnscrypt.org/#dnscrypt-proxy
    do-not-query-localhost: no
 
    # Use the following forward-zone to forward all queries to Google DNS,
    # OpenDNS.com or your local ISP's dns servers for example.
    # To test resolution speeds use "drill calomel.org @8.8.8.8" 
    # and look for the "Query time:" in milliseconds.
    #
    forward-zone:
        name: "."
        #forward-addr: 8.26.56.26        # Comodo DNS
        #forward-addr: 8.20.247.20       # Comodo DNS
        #forward-addr: 8.8.8.8           # Google Public DNS
        #forward-addr: 8.8.4.4           # Google Public DNS
        #forward-addr: 74.82.42.42      # Hurricane Electric
        #forward-addr: 4.2.2.4          # Level3 Verizon
        #
        # Uncoment if you wish use Unbound through dnscrypt-proxy
        # http://dnscrypt.org/#dnscrypt-proxy
        forward-addr: 127.0.0.1@40      # dnscrypt-proxy
        forward-addr: 127.0.0.1@41      # dnscrypt-proxy
#
#
## Authoritative, validating, recursive caching DNS
## unbound.conf -- http://www.remoteshaman.com
 
---
 
# /opt/dnscrypt/sbin/dnscrypt-proxy --ephemeral-keys --resolver-name=dnscrypt.eu-nl --local-address=127.0.0.1:40 --daemonize
 
# /opt/dnscrypt/sbin/dnscrypt-proxy --ephemeral-keys --resolver-name=dnscrypt.eu-nl-port5353 --local-address=127.0.0.1:41 --daemonize
 
---
 
# vi /etc/rc.local
 
/opt/dnscrypt/sbin/dnscrypt-proxy --ephemeral-keys --resolver-name=dnscrypt.eu-nl --local-address=127.0.0.1:40 --daemonize
/opt/dnscrypt/sbin/dnscrypt-proxy --ephemeral-keys --resolver-name=dnscrypt.eu-nl-port5353 --local-address=127.0.0.1:41 --daemonize
 
---
 
# systemctl restart unbound

Запуск DNSCrypt от non-root пользователя

ДНС-ресолвер Unbound, многие часто по ошибке называют его ДНС-сервером, после установки по умолчанию запускается от имени пользователя unbound.

Любые попытки запустить DNSCrypt от имени пользователя nobody закончатся ошибкой "[ERROR] Unable to chroot to [/nonexistent]", поэтому для запуска DNSCrypt от имени ограниченного пользователя (ака non-root) нам потребуется сначала создать его и у него должна быть реальная домашняя директория.

Делаем пользователя dnscrypt (на любые вопросы жмём Enter): adduser --disabled-login --shell /bin/false dnscrypt

Запускаем DNSCrypt от имени non-root пользователя: /opt/dnscrypt/sbin/dnscrypt-proxy --ephemeral-keys --resolver-name= --local-address=127.0.0.1:53 --user=dnscrypt --daemonize

Проблемы?

unbound-control[...] error: connect: Connection refused

Если не изменялась конфигурация по умолчанию, то всё должно быть в порядке, а если же в директории /etc/unbound/unbound.conf.d/ были созданы дополнительные конфигурационные файлы, то при использовании unbound-control возможны такие вот проблемы:

# systemctl restart unbound
# unbound-control reload
ok
# unbound-control reload
[1446250350] unbound-control[25955:0] debug: address 127.0.0.1 port 8953
[1446250350] unbound-control[25955:0] error: connect: Connection refused
--- или ---
# systemctl restart unbound
# unbound-control reload
ok
# unbound-control stats
[1446250350] unbound-control[25955:0] debug: address 127.0.0.1 port 8953
[1446250350] unbound-control[25955:0] error: connect: Connection refused

В любом случае после первого выполнения unbound-control reload ДНС-ресолвер перестаёт отвечать и требуется перезапуск systemctl restart unbound.

Где проблема, в самом unbound (но нет же, запускается/перезапускается успешно) или в unbound-control, можно только гадать? Короче, чтобы избежать этих проблем (версия unbound 1.4.22), конфигурационный файл должен быть один с одной секцией server: ...

Unbound не пишет в unbound.log

По умолчанию Unbound пишет в syslog, однако есть возможность писать события в отдельный файл журнала - в unbound.log. Для этого директива "use-syslog:" должна быть установлена в "no" и при этом файл указанный в "logfile:" должен физически присутствовать на диске, владельцем которого должен быть unbound:

# touch /etc/unbound/unbound.log
# chown unbound:unbound /etc/unbound/unbound.log
 
# vi /etc/unbound/unbound.conf
server:
  logfile: "/etc/unbound/unbound.log"

Проблемы с forwarding-ом DNS-запросов

Если Unbound продолжает перенаправлять запросы на сторонние сервера, а не на те что мы указали в "forward-zone:", тогда открываем /etc/default/unbound, доводим его до следующей ниже кондиции и перезапускаем Unbound:

# vi /etc/default/unbound
 
# If set, resolvconf nameservers will be configured as forwarders
# to be used by unbound.
RESOLVCONF_FORWARDERS=false
 
DAEMON_OPTS="-c /etc/unbound/unbound.conf"

DNSSEC Validator браузера Firefox пишет о неправильном IP

DNSSEC/TLSA Validator браузера Firefox иногда может выдавать ложную тревогу о том, что IP-адрес полученный браузером не совпадает с тем, который был получен расширением, как на скриншоте ниже:

firefox-dnssec-validator-invalid-ip-for-debian-org

На скриншоте говорится о том, что IP-адрес 150.203.164.38 полученный браузером не совпадает с IP 5.153.231.4/130.89.148.14, что даёт основания подозревать попытку атаки "DNS spoofing". Проверим:

$ nslookup debian.org
Server:    127.0.0.1
Address:  127.0.0.1#53
 
Non-authoritative answer:
Name:  debian.org
Address: 5.153.231.4
Name:  debian.org
Address: 128.31.0.62
Name:  debian.org
Address: 130.89.148.14
Name:  debian.org
Address: 140.211.15.34
Name:  debian.org
Address: 150.203.164.38
Name:  debian.org
Address: 200.17.202.197
 
$ nslookup debian.org 8.8.8.8
Server:    8.8.8.8
Address:  8.8.8.8#53
 
Non-authoritative answer:
Name:  debian.org
Address: 130.89.148.14
Name:  debian.org
Address: 140.211.15.34
Name:  debian.org
Address: 150.203.164.38
Name:  debian.org
Address: 200.17.202.197
Name:  debian.org
Address: 5.153.231.4
Name:  debian.org
Address: 128.31.0.62

Видим, что nslookup debian.org (запрос через наш локальный ДНС-ресолвер) и nslookup debian.org 8.8.8.8 (запрос через ДНС-ресолвер гугла) выдаёт одинаковый список IP-адресов, а это значит, что DNSSEC/TLSA Validator браузера Firefox выдал ложную тревогу.

По умолчанию DNSSEC/TLSA Validator браузера Firefox настроен (Инструменты - Дополнения - Расширения - DNSSEC/TLSA Validator - Настройки) как "Without resolver" и использует "DANE протокол" для проверки DNSSEC для домена. Потому как при наличии нескольких А записей для домена они выдаются динамически, то вполне вероятно что ложная тревога обусловлена несогласованностью между результатами запроса локального ресолвера и самого расширения.

Решить эту проблему можно установив в настройках расширения "Resolver settings" вариант "Custom:" и IP ресолвера "127.0.0.1", далее нажать "Test current settings" на что должны получить "Success - current settings allow DNSSEC validation.".

Итого

Установка Unbound DNSSEC с переадресацией запросов в DNSCrypt оправдана тем, что:

  1. DNSSEC на данный момент поддерживают очень мало ДНС-провайдеров, а своему ISP мы не доверяем;
  2. DNSCrypt не кэширует запросы, а Unbound как раз наоборот.

Вместо Unbound для кэширования ДНС-запросов можно установить "nscd - GNU C Library: Name Service Cache Daemon", однако он глючный и в Debian не установлен по умолчанию.

Напомним, что использование шифрования ДНС-трафика с помощью DNSCrypt не скрывает сам ИП-адрес и доменное имя сайта к которому обращается приложение, а только даёт некую уверенность в том, что результат ДНС запроса не будет подменён местной "прослушкой". При использовании не зашифрованного HTTP соединения доменное имя (заголовок Host), как собственно и строку запроса (Request-Line) можно выдрать из "Request Headers". Однако при использовании HTTPS, "прослушке" будут доступны только IP-адреса имхо перед началом передачи "Request Headers" происходит установка защищённого TCP соединения (via SSL/TLS protocol) и уже после клиент/браузер отправляет HTTP request (методом GET или POST) по зашифрованному TCP соединению.

Unbound DNSSEC совместно с DNSCrypt не является решением вопроса полной 100% анонимности, которой не может быть в принципе, а только лишь меняет доверенного поставщика с местного, как правило "подкаблучного" ISP (Internet Service Provider), на как нам кажется более надёжного и анонимного европейского поставщика ДНС-услуг от которого большей частью теперь и будет зависеть безопасность всех наших ДНС-запросов.

P.S. При возможности шифровать нужно всё что только можно!


Комментарии   

АдМинь БагоИскатель
0 #4 АдМинь БагоИскатель 24.12.2015 09:11
:bayan: Ай да стою ж я на асхвальте у лыжи обутый, чай то лыжи не едут, чи то я ...нутый...

Сегодня при чиргавом подвисе решил пересмотреть правила в iptables-е и для некоторых включил лог, - долго ждать не пришлось:
Цитата:
iptables denied via psd mod: IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:09:00 SRC=127.0.0.1 DST=127.0.0.1 LEN=107 TOS=0x00 PREC=0x00 TTL=64 ID=1525 PROTO=UDP SPT=53 DPT=51208 LEN=87
"psd mod" се есьм "Port Scan Detector" из дополнений xtables. Пересортировал порядок правил iptables, надеюсь теперь всё будет гуд.

Поэтому расширения Firefox оставляем в покое и смотрим на свои брандмауэры :D
Цитировать
Иван Шаман
0 #3 Иван Шаман 22.12.2015 09:23
Цитирую АдМинь БагоИскатель:
Эта связка у меня что-то тормозит, запросы по многим доменам сдыхают, но по отдельности работает отлично.

Пока юзаю один только DNSCrypt с одним из dnscrypt-резолверов поддерживающих DNSSEC и этого вполне достаточно, ну а то что запросы не кэшируются, то это думаю ерунда.

Думаю товарищи проблема здесь не так как в самой связке Unbound и DNSCrypt, а в кривом расширении DNSSEC Validator для браузера Firefox - если оно используется.

Так даже при использовании одного только Unbound он время от времени подвисал на 1-2 мин. и отказывался ресолвить имена nslookup-ом выдавая отлуп мессагой ";; connection timed out; no servers could be reached".

Взглянув на открытые соединения "lsof -nPi | grep \:53" я подметил что браузер, в моём случае palemoon, навис на 53-й порт - постоянно было открыто более 7-8 процессов подключенных на локальный 53-й порт, а временами это число увеличивалось до 20 и более. Стоило только закрыть palemoon и сразу всё приходило в норму, nslookup начинал возвращать запрашиваемые данные.

Поведение palemoon в данном случае напоминает признаки "DNS Amplification Attacks Observer: Authoritative Name Server attack": http://dnsamplificationattacks.blogspot.com/2014/02/authoritative-name-server-attack.html

После полного удаления "DNSSEC Validator для браузера Firefox", отключение с перезапуском браузера кажись не помогло, palemoon успокоился и больше не нависал на 53-й порт независимо от количества открытых вкладок.

Вот так тоже бывает :-) Поэтому проблема не всегда может быть в сервере, а ещё и в клиенте.
Цитировать
Олег Головский
0 #2 Олег Головский 01.12.2015 03:28
Цитирую АдМинь БагоИскатель:
Эта связка у меня что-то тормозит, запросы по многим доменам сдыхают, но по отдельности работает отлично.

Пока юзаю один только DNSCrypt с одним из dnscrypt-резолверов поддерживающих DNSSEC и этого вполне достаточно, ну а то что запросы не кэшируются, то это думаю ерунда.

Некоторые dnscrypt-сервер а бывает не отвечают вовремя из-за перегрузки в итоге негативный результат запроса кэшируется unbound-ресолве ром (на сутки обычно), что заставляет время от времени выполнять unbound-control reload, хоть можно и на крон поставить, но толку всё равно мало имхо - поэтому, да, целесообразно будет юзать либо dnscrypt либо unbound.

Кстати, для dnscrypt, в каталоге с исходниками, есть шэл-скрипт resolvers-check .sh для проверки доступности ресолверов из списка dnscrypt-resolv ers.csv - после проверки список доступных скриптом сохраняется в dnscrypt-online-resolvers.csv.

Список ресолверов меняется чуть ли не по десять раз на дню: https://github.com/jedisct1/dnscrypt-proxy/blob/master/dnscrypt-resolv ers.csv
Цитировать
АдМинь БагоИскатель
0 #1 АдМинь БагоИскатель 07.11.2015 13:09
Эта связка у меня что-то тормозит, запросы по многим доменам сдыхают, но по отдельности работает отлично.

Пока юзаю один только DNSCrypt с одним из dnscrypt-резолв еров поддерживающих DNSSEC и этого вполне достаточно, ну а то что запросы не кэшируются, то это думаю ерунда.
Цитировать

Добавить комментарий


Защитный код
Обновить

10 megabytes